Window stacking

[Sam Spilsbury]

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

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


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

This should not be in the windowing system API since different
environments may associate different data with applications or
application groups.

>
> 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.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Sam Spilsbury