[PATCH weston 3/8] westoy: Use subsurfaces for tooltips instead of transient windows

Bill Spitzak spitzak at gmail.com
Thu Nov 14 12:47:03 PST 2013

Jasper St. Pierre wrote:

> Transients, as they existed in wl_shell_surface, have been removed from 
> xdg_shell and aren't coming back. There is a new set_transient_for 
> request, but it's more to provide something like the ICCCM 
> WM_TRANSIENT_FOR property: associating modal dialogs with their "parent 
> window".

My main concern is that this not be screwed up in Wayland. Gregory 
Merchan is also trying to get this to not be screwed up. The client MUST 
be in charge of window stacking and whether a window is mapped or not.

Our proposal pretty much amounts to this:

- Client at any time can take any of it's surfaces and set it's parent 
to another surface or to none. The only error is that a loop of parents 
is not allowed. If you want you can call the parent the "transient for" 
but I think that is really ugly.

- This has no visible effect even if the current window stacking is 
"wrong". However any raise, map, or unmap a client requests will cause 
all "child" surfaces to also be raised, mapped, unmapped. This allows 
changes to the tree to be atomic with other commits.

- Compositor is not allowed to raise or map or unmap any surface except 
when client requests it. Thus the client can always alter the tree 
before any of these actions.

The purpose is to allow non-trivial stacking rules (in particular 
floating toolboxes shared my more than one main surface), while still 
providing an api that is not complex and supports the trivial cases and 
can be replicated on remote hosts with antique window management rules.

I personally feel that subsurfaces and child windows are identical, 
except that a subsurface is always kept next to it's parent in stacking 
order, while a non-subsurface can have other surfaces between it and 
it's parent.

More information about the wayland-devel mailing list