In this example window C must always remain above windows A and B, but there is no other restrictions. There are 8 possible window arrangements where C is above both A and B. This diagram shows all the transitions (the head of the arrows is marked with which window is raised). I would consider it a bug if any of these transitions do not work, especially if it means that not all 8 states can be reached.
There are several scenarios where the desire to arrange windows like this comes up:
1. A and B are two documents, C is a "toolbox" to work on A and B, and D is an unrelated client.
2. A and B are two windows in an application, C is a mac-like menubar for that application, and D is an unrelated client (which may have it's own menubar).
3. A and B are non-fullscreen windows, C is the "panel", and D is a fullscreen window.
4. A and B are normal clients. C is a "notification". D is a client that wants to raise above notifications.
No current window system supports this correctly:1. A "layer" system, where C is in a "layer" that keeps it above A and B, prevents the blue states.
2. A "transient-for" system, with C being transient-for B, does not allow the red states.
3. A "layer+application" system such as used on OSX, where A,B,C belong to the same application and C is marked as a "dialog" does not allow the green states.
Most programs work around these problems by destroying and recreating surfaces (usually C) but this results in on-screen blinking. They also just give up and resort to a single tiled window, in effect implementing their own window manager because they cannot use the system's.
My proposal is to use a "transient-for" system except to allow the "transient for" to be changed arbitrarily. The client would change C's transient-for between A and B before raising A or B. Otherwise it would just tell Wayland to raise surfaces as they are clicked.
Other possibilities are:1. Communicate an entire DAG (directed acyclic graph) to the compositor. Thus the fact that C remains above both A and B is known by the compositor. I don't like this due to the difficulty of clients reliably editing this data structure (such as accidentally not breaking an edge that they don't want).
2. Don't send anything, instead the client has a "put A under C" as well as plain raise. This certainly allows any combinations, but does not send useful information about window connections to the compositor, and has race conditions if the windows are from different clients.
<<inline: foo.jpg>>
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
