Window stacking

[Sam Spilsbury]

On Wed, Sep 14, 2011 at 11:35 PM, Giovanni Campagna
<scampa.giovanni at gmail.com> wrote:
> Il giorno mer, 14/09/2011 alle 21.56 +0800, Sam Spilsbury ha scritto:
>> On Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> > 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.
>> >
>>
>> So this is essentially just like X11's synethetic ConfigureRequests
>> and ConfigureNotify events delivered to clients.
>>
>> I don't think it makes sense to let clients have control of toplevel
>> stacking. If they wanted to have window groups which are kept in sync,
>> it seems to me to create a large buffer with a custom input shape (if
>> such a thing exists in wayland) such that windows are raised and
>> lowered in groups, rather than having to ask the window manager to fix
>> the stacking every single time the user raises a toolbox window. (see
>> the WM_TRANSIENT_FOR and _NET_WM_STATE_MODAL nightmare that WM's have
>> to deal with right now).
>
> Is it a nightmare, or is it a feature, that the WM decides the stacking
> order?
> Not all WM behave in same way, and most of them are customizable in some
> form, which is, IMHO, a benefit for the user, that can pick the behavior
> he prefers. I think having a single partially transparent window is a
> limitation and would not improve the story with stacking; plus it would
> increase the complexity of toolkits (just look at the amounts of code
> GDK has for client-side windows)

The fact that the window manager does this stuff is not bad, what I
was getting at was the way that the window manager is interfaced with
at the moment.

At the moment you do window management in X by making requests
directly to the server and then some of them are redirected to the
window manager and some of them are not. This means that window
managers have very little control over what's actually going on. The
largest problem a lot of window managers face is keeping the internal
stack representation in sync with whats going on server-side, which
involves a lot of timing-dependent code.

Dependency resolution with transient and modal windows is also very
difficult to get right as there are subtly different stacking rules of
situations where clients create lots of windows for the same
application. If the desired end result is to have those windows on the
same layer it would make sense to have the client create a single
surface and do the compositing by itself (the window management policy
in this case can always be pushed out into a separate library, there
is no need to have the toolkits manage this).

>
>> > 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.
>> >
>>
>> So essentially XConfigureWindow. I'm skeptical of having this built
>> into the wayland protocol itself, mainly because I'm more of a fan of
>> having window management done in a separate API to the windowing
>> system, but I think those ideas need to be detailed later (and even
>> then it's probably too late).
>
> Well, the window manager, the compositor and the display server are
> finally the same process, and this is the very big point of wayland, so
> it any, it should be all together.

Having the window manager out of process is an idea I am a fan of (for
various reasons which I won't get into) and I don't think it would be
difficult to do, as long as you have the "chain of command" situation
right (eg, clients use an explicit window management API and all
requests relevant to window management are done via the window manager
library)

> Btw, so far the WM stuff has been
> kept in one interface wl_shell, so it is possible to replace it at a
> later time with a wl_shell version 2, without changing the other API.
> So you don't need XConfigureWindow telling the display server that the
> window manager wants to change the stacking order, and you don't need
> ConfigureNotify telling the compositor that the display server has
> changed the stacking order.
>

Good. :)



-- 
Sam Spilsbury