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

[Bill Spitzak]

On 10/15/2013 10:53 PM, Kristian Høgsberg wrote:

>      - transient for shouldn't take position.

What? I think that is necessary. It is relative to the parent surface.

>      - New keyboard focus protocol: instead of active surface meaning
> "has keyboard focus" we need something that works in a touch-only
> environment and we need a more generic way to create surfaces that
> don't take keyboard focus.  I propose a new xdg_surface.activate event
> that indicates that the surface has been activated (by clicking or
> touching or alt-tabbing to it (or hovering in case of sloppy focus)).
> When a surface is "the active surface", the client can choose to
> assign kb focus (xdg_surface.take_keyboard_focus) to any of its
> surfaces.

Please allow clients to take the active themselves, maybe with a 
xdg_surface.take_active request, and clients can decide themselves 
whether a click or hover activates them. The compositor should not 
activate surfaces due to events done to the surface (it can still 
activate them due to things like alt+tab shortcuts and due to the 
current active surface being unmapped).

This will allow clients to decide not to activate themselves, to make 
the rules vary depending on where the events happen, and so that 
point-to-type is a per-client rule, not a global one.

Hostile clients will not be able to grab the active, as the active 
request will contain an event id that triggered it, and the compositor 
can ignore it if the event is not a keystroke or mouse event to that client.

>      - We need to solve stacking - how does a wayland shell raise an
> applications and all its surfaces correctly.  The two ideas I have are
> either 1) let the client raise its surfaces when it's active (uses the
> same xdg_surface.activate event as above) and just let the client
> control which surfaces to raise and in which order in response to
> being activated or 2) let the client describe above/below relation
> between its surfaces and make sure the shell respects these
> constraints when raising a surface (eg, toolbars above documents, but
> no relation between individual toolbar surfaces or doc surfaces.
> Raising a document raises all the toolbox surfaces to be on top, but
> doesn't affect other documents and preserves the stacking order of the
> toolbox surface).

I am in favor of a hybrid approach. Version 1 above should always work: 
a client can make a bunch of surfaces, not communicate any relationship 
information about them to the compositor, and always have complete 
knowledge and control over what order they are composited in. It can 
insure that top-to-bottom order of 3 surfaces is A,B,C by raising B and 
then raising A. And the compositor must *NEVER* raise surfaces itself. 
Surfaces are ONLY raised in response to a request from the client. This 
means the client always knows exactly what order they are in.

However the compositor should also support a tree of parent 
relationships between surfaces, which a client may choose to use. Each 
surface has a "parent", which is either null or another surface. If 
surface A has a parent of B, a raise of B will also raise A, and a 
map/unmap of B will map/unmap A. A client can at any moment change the 
parent of any surface to any other one except it can't make a loop, 
changing the tree will not change the state or position of any surface 
even if it is "wrong", the tree only controls what happens when requests 
are made to parents.

The reasons for supporting the tree (rather than have the client do 
everything) are:

1. Pagers and task switchers can use this tree to determine that a bunch 
of surfaces are related

2. Compositors may be able to take advantage of knowledge that two 
surfaces are 'stuck together' and will raise as a unit. In particular it 
can take advantage of everything being done for subsurfaces.

3. Familiarity and resemblence to other window systems.

I believe these child surfaces and "subsurfaces" are EXACTLY the same 
thing. The only difference is that raising a subsurface puts it just 
above the top-most subsurface with the same parent, while raising a 
non-subsurface puts it at the top of it's layer, above surfaces 
belonging to other clients. Merging sub, transient, and popup surfaces 
will simplify wayland and provide advantages to both that currently only 
exist for one or the other.

Because nothing happens unless raise or map requests are made from the 
client, the client is still in control. It can change the tree any way 
it wants before doing a raise request.

The common example of a floating dialog over two main windows would be 
accomplished by the client changing the parent of the dialog to the main 
window it is raising. This ability to change the tree avoids the need to 
send a directed acyclic graph to the compositor, vastly simplifying the 
compositor api.