Window stacking

[Bill Spitzak]

Along with all the discussion about client-side decorations, there is 
also a need for client-side window stacking and mapping.

In current window managers it is almost impossible to make 
multiple-window complex applications. For instance the Gimp has been 
forced to abandon this idea. And in professional software, especially 
stuff with Windows versions, every single program has resorted to a 
single "tiled" window that fills the screen.

There may be reasons to not have such applications, but one reason was 
that it was virtually impossible to control the window stacking order 
using the window system api, which typically consisted only of the 
"transient for" ("child" on Windows) attribute, and in more recent 
desktops some "keep on top" flags.

For Wayland I would like to see the following, all very similar to how 
resize is working out:

1. Part of the Wayland api is that all the windows displayed by the 
compositor are in a single list that defines their stacking order. The 
compositor is expected to obey this (though it can disobey to prevent 
devious clients from taking over the screen).

2. There is a *atomic* api by which a client can map, unmap, and change 
the stacking order of it's own windows. This is probably a "put a 
above/below b" call (where b==None puts it at the bottom/top), and some 
unmap/map calls. All the changes are applied at once so the compositor 
either produces the "before" or the "after" composite, but never any 
intermediate one.

3. Like resize, there is a compositor->client "notify" call that looks 
identical (though I don't think it has to support multiple changes). 
Client is expected to do the change, but may also move and map or unmap 
and restack other windows. For instance it can keep floating dialog 
boxes and toolbars atop it's main windows. It can also keep windows with 
different pixel sizes directly below windows so the user cannot see the 
video playback is different from the frame around it.

4. Also like resize, there is a client->compositor "request" call that 
looks just like the notify. The compositor is expected to respond with 
the notify call, though it may alter it to obey keep-on-top and other 
such rules.

A few other ideas:

1. It seems likely that this should be merged with the resizing 
requests, and with activate/deactivate and focus changes. All window 
management should be a single call that can make all changes to the 
windows, with matching request and notify calls. There should be a 
library function to "concatenate" window management messages so that a 
series of them can be turned into a final one which is the only one a 
program needs to obey.

2. For task managers the windows are going to have to have some 
associated data with them, such as the text and icon, etc. Should this 
be in the wayland api, or should ipc from the task manager to the actual 
client be used?

3. Also for task managers it would be useful to make "application" 
windows that do not have images and never really map. These are 
displayed by task manager type applications. Requests to window-manage 
these should cause clients to also make related changes to visible 
windows. This is needed for multiple-window apis.