Window stacking

[Giovanni Campagna]

Il giorno mar, 13/09/2011 alle 21.13 -0700, Bill Spitzak ha scritto:
> 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.

Why isn't transient for + window type (like _NET_WM_WINDOW_TYPE) enough?
As I see it, the only strong policies you want to apply are:
1) keep utility windows on top of their parents, and make them not
overlap; make it impossible to stack anything between the parent and the
utility window
2) keep override-redirect windows on top of their parent, keep nothing
between them and their parent, and keep the relative position
3) map non modal dialogs on top of their parents, and raise them when
the parent is raised
4) keep modal dialogs above their parent (possibly attached to the title
bar), keep nothing between them and the parent, raise the parent when
the dialog is raised
5) prevent overlapping with docks and side-panels (generically, anything
that affects stuts)
6) respect user decisions (such as "keep this window on top")
And as with every policy, to me the best place for this is the
compositor.

Btw, at the desktop summit, there was a talk comparing the UI of Gimp
with that of Inkscape, and the blaming of the multiple window paradigm
had nothing to do with stacking, so it's possible that professional apps
are single-window in Windows not because they can't do otherwise but
because they are more usable and look better.

> 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).

Well, clients cannot see resources that belong to other clients (object
ids are per client, since wl_display.bind was introduced), which means
that the "big window list" is server-side only. And obviously, I expect
the compositor to obey itself :)

> 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.

Certainly it must be atomic, but I see this part completely compositor
side. Differently from resize, in which you have to prepare a new
buffer, there is nothing the client needs to do when the stacking order
changes. The buffer is already there, is just a matter of drawing it in
a different order.
Also, clients should not stop updating a window just because it's not
visible. Most of time, it will be visible in some other way (Plasma
thumbnails, Compiz Expose, Mutter Activities overview)

> 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.

Do we notify clients of restacks in X11? And do toolkits make anything
out of that?
(Honest question)

> 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.

I perfectly agree, and in fact, I have a wl_shell.restack as part of my
"EMWH" branch (github.com/gcampax/wayland/desktop-shell-2). As far as I
see it, that's all we need.

> 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.

1) Focus changes are per-input-device (to avoid the Core Pointer / Core
Keyboard X11 mistake), so they would be difficult to integrate properly
in wl_shell.
2) In my branch, wl_shell.activate is a single request (modeled after
gtk_window_present) that acquires keyboard focus and restacks to the top
all at once; parallel to that, you have wl_shell.restack.
I made this distinction because often policies are different: in
Mutter/X11, gtk_window_present (XConfigureWindow + XSetInputFocus) most
of time has not the effect the client expects, and the window is just
given the "demands attention" bit. OTOH, if we want to let clients have
some control of stacking, we must ask compositors to obey
wl_shell.restack (they may ignore it anyway, for example for focus
stealing prevention in focus follows mouse mode).
3) Like gtk_window_present does two X protocol calls, we can have a
single toolkit call doing more wayland requests, handling events,
roundtrips and everything. But that's a matter of toolkit design, not
protocol.

> 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?

Among the three major WMs, KWin is the only one that is keeping the
desktop shell in a separate process, and they're implementing a private
DBus API for Plasma. Once it stabilized, they said there was no problem
with making it a freedesktop standard, but they weren't really
concerned.
As for the GNOME side of things, I don't know how long we want to
support using the Shell with cairo-dock, awn or docky, especially given
we have a powerful in-process extension system.

> 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.

I guess you mean the equivalent of the "group leader" window in X
terminology. We could allow to map a window transient to an unmapped
one, or we could have toolkits map a transparent window with no input
shapes. In either case, I don't see a need to for special "application"
windows (also, application matching is usually done with WM_CLASS and
pid, not window groups).

Giovanni


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110914/9b6b0d96/attachment.pgp>