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