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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
