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

[Bill Spitzak]

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.