Gregory Merchan wrote:
As Bill mentioned in a follow-up, drag sources would want to not activate.
This can be handled more simply than described above, without a
special "activate" system. I assume "activation" applies to a window,
not a client.
I believe you are describing the system I was thinking of, where
Alt+Tab, etc, are done by the compositor directly activating clients,
while point-to-type and click-to-type is entirely the client's
responsibility, in that they activate themselves (and thus can decide
that a click or mouse movement should *not* cause an activation).
Jason Ekstrand's complaint about this is that it takes whether the
system is set to "point to type" or "click to type" out of the
compositor's control. Therefore he would like some kind of communication
from compositor to client saying "you probably should activate now". I
think this might also be an indication of "the compositor will not
ignore an activate from you now". Point-to-type would do this on mouse
enter, click-to-type on mouse clicks.
1. PointerRoot: Activates a window when the pointer enters it and
deactivates it when the pointer leaves.
I think this can be ignored and only sloppy implemented. There is no
difference if the entire screen is filled with non-desktop clients.
2. Sloppy: Activates a window when the pointer enters it.
This is equivalent to "the desktop does not activate when the pointer
enters it". I would like all clients to have this ability, not just the
desktop.
5. Windows/MacOS-style: Does not activate a window, except as it does
for all policies.
Not sure what you mean here. Windows is pretty much the same as X
click-to-focus. OS/X "eats" the click that activates the application,
but I believe this is entirely done by the client, and a client could in
fact respond to the click if it wanted.
For each of these policies, another distinction may be made according
to signature required to honor an activation request.
The compositor is totally allowed to ignore any activation request. The
most common reason is because another client has activated itself based
on a later event.
For example, this allows an
active program to activate a dialog, but prevents other programs from
activating any windows.
This is not a problem. In Wayland it is *clients* that are activated,
not "windows". The client is free to draw highlights and blinking
cursors and anything else so that the user thinks some particular
transient window has the keyboard focus, but the compositor is unaware
of this (though info may leak due to the input method text cursor
position?).
It may be useful for a client to tell the compositor which surface it
thinks is active, so that pagers can perhaps highlight this info. This
should be allowed if the client is already active, but has zero effect
on the behavior or events delivered by the compositor.
To my knowledge, both Windows and MacOS already require
applications to request activation in this way
Windows has an elaborate kludge. Basically it acts like X in that clicks
always activate applications. However if the application manages to do
the right system calls so that Windows thinks something is being dragged
it then undoes the activation. This can botch up if the other active app
dies just at this moment.
I don't know about OS/X.
In any case what you want is the way Wayland should work, no matter what
Windows and OS/X really do.
I have said nothing about stacking. Handling activation as I have
described allows for every kind of stacking behavior I've seen, except
for one: raise on frame clicks, but not on clicks within the frame.
The client must be entirely and 100% in control of stacking. No window
should ever raise unless the client has explicitly sent a raise request.
This must be true otherwise you will have to add the nightmare of a
continuously updating directed acyclic graph of surface relationships,
which would probably double the size of the Wayland api.
Therefore raising on frame clicks only (or any other subset of the
surface) is trivial and the client's responsibility.
This exception exists when the compositor is not responsible for
drawing the window frame, because nothing I have described allows the
compositor to distinguish between parts of the client window.
No this is absolutely irrelevant. The compositor NEVER NEVER NEVER
raises a surface unless the client requests it. Therefore it does not
need any knowledge of the areas of the surface!
Remote display on servers that require the server to add borders will
just not do the raising correctly. Hopefully it can be simulated
reasonably well since it will at least have the window tree and it won't
change too often, and the user can find and raise windows by clicking on
the borders for the few cases where it screws up. I would not waste
development time on trying to improve this.
I believe a simple stacking policy would be to allow a client with an
active window to do anything it wants with its windows within the
bounds set by other features; basically it can do anything as long as
it doesn't put windows below stay-on-bottom features, like the
desktop, or above stay-on-top features, like task bars and menus.
IMHO the only actions the client needs are to be able to "raise" a
surface. The compositor will choose exactly what this means, though it
probably means to put it at the top of all similar surfaces. The client
must also be able to set the window tree, and this means that the
compositor should treat a raise of a parent as being immediately
followed by a raise of each child surface, and perform all this atomically.
I suppose there is a need to "lower" a surface which is what clients
might do in response to a middle mouse click on a window border to match
many X window managers. Though this might be the "deactivate request"
that was suggested. I don't think users use this except as an equivalent
to alt+tab.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
