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