Window stacking

[cat]

this might be a question more for these programs than for this list,
but how can one of these programs handle the full desktop realestate?
wouldn't that itself force the same condition that you have with the
rogram being a single window?

On Tue, Sep 13, 2011 at 11: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.
>
> 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.
>
> 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?
>
> 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
>