[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Bill Spitzak]

Gregory Merchan wrote:

 >> re: glitches in pagers due to incorrect guessing of activated 
surface by comnpositor

> I think the API for marking surfaces transient or otherwise secondary
> will obviate some potential glitches. For example, I think most
> thumbnailing window switchers I've seen just ignore transients.

Yes I agree which is why I don't think these glitches are a real problem

> I don't think that's a good assumption to make, because I know I won't
> be using sloppy focus and I'll then be seeing multiple redraws from
> assuming clients responding to crossing events.

Okay, I think I still misunderstood what you are asking for.

I now believe you are asking for clients to always send an activate 
request on mouse enter, and the compositor to ignore these if sloppy 
focus is not on.

What I was proposing is that the client knows whether sloppy focus is on 
or not, and it only sends activate requests on mouse enter if it is on.

I think under your scheme the client could still predict whether it will 
get activation, by remembering from the previous mouse-enter whether it 
worked or not.

You could also combine both schemes. Both the client and compositor need 
sloppy focus turned on for it to work (if they are both reading the same 
configuration this is not a problem).

> I think I'll have to just think about this for a while. I personally
> don't like sloppy focus because I believe a better system can be built
> when it is not allowed, but a system with fine-grained sloppy focus
> would be very different from any I've considered. This last request
> for a description was more personal curiosity than relevant to
> Wayland.

My absolute #1 concern is that clients be able to be clicked and respond 
to these clicks without raising, activating, or taking the keyboard 
focus. The current behavior of Windows and the Gnome window manager make 
non-trivial use of multiple windows impossible, and all modern software 
has been forced to resort to a single full-screen tiled window with it's 
own "window management" to avoid this bug. Gimp is the only well-known 
example of a program trying (and failing) to work around the bug. My 
software (the Nuke Compositor from The Foundry) will also try to do it 
if you turn on "floating parameter windows", and there are configuration 
checkmarks to change whether the window manager is Gnome or KDE to try 
to get around the bugs, but it really is quite impossible).

Because Windows fixed this for clicks that start a drag & drop for 
Explorer, it is easiest to describe this as fixing drag & drop, since 
there are far more users familiar with this limited fix than the general 
one.

A secondary concern is that point-to-type remain possible, though I am 
fine with it only working in clients that understand it, and am also ok 
with a global switch to make it not work even if the client wants it.