Window stacking diagram

[Bill Spitzak]

Not sure how useful this is, but I made a graph showing the necessary 
window transitions that Wayland should support, in an attempt to show 
why "layers" are not sufficient.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.jpg
Type: image/jpeg
Size: 38771 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20121230/fd69ea15/attachment-0001.jpg>