Window stacking

[Giovanni Campagna]

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)

> > 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. 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.
-------------- 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/4d852f16/attachment-0001.pgp>