Window stacking

[Samuele Disegna]

Hello, I am Samuele. From Italy

Just an idea: (probably a crazy idea, but I don't know)
Why not to setup non-rectangular windows?
ie. windows with one or more buffers stacked in order.
Isn't true that:
This will handle the raised problem and still keep a simple concept of
wayland. ?

On Wed, Sep 14, 2011 at 5: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)
>
>> > 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.
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>