Window stacking

[Giovanni Campagna]

Il giorno mer, 14/09/2011 alle 11.24 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
> 
> > Why isn't transient for + window type (like _NET_WM_WINDOW_TYPE) enough?
> 
> Because it does not allow *MULTIPLE* parents.
> 
> In gimp if you have 2 image windows, you want the toolbars to remain 
> atop *BOTH* of them. This is not possible to describe with a single 
> "parent" from each toolbar window.
> 
> Note how INCREDIBLY TRIVIAL it is for a client to do it (raise of any 
> window means raise all the toolbars!). It literally requires about 
> 1/10th the code and complexity than any api that describes "window 
> groups" or whatever insane scheme is being described.

Understood.
Yes, this is partially trivial to do from the client-side (not
completely trivial, because toolkits are designed after the
"parent-child" relation, so it would be handled by the application or
require API changes).
Except that I'm not convinced it's worth the complexity of two requests
and one event. Also, when it comes to resize, there is a (rather
complex) way for the compositor to check if an attachment is complying
with the policy or is coming out of nowhere, whereas there is no way for
the compositor to check a "really_restack" request, which breaks any
serious enforcement.

On the other hand, the most common cases are already handled by
transient_for. Code is already there (and will stay there, for X11
compatibility), so there is no added complexity. Also, parent-child is
required for modality.
If the Gimp case is really worth fixing, we can go with the unmapped
parent creating a window group. Then the policy can be: within a window
group, normal windows are stacked normally; utility windows are stacked
like other utility windows, but are raised when any of the normal window
in the group is raised.
Btw, stacking policy is hard to get right (for example, do you lower the
utility windows when lowering a normal one?), it's better to fix it once
for all in the WM.

> > Btw, at the desktop summit, there was a talk comparing the UI of Gimp
> > with that of Inkscape, and the blaming of the multiple window paradigm
> > had nothing to do with stacking,
> 
> Bull. Every single complaint was about window stacking. I challenge you 
> to list a single complaint that is not either "the toolbar hid my stuff" 
> or "my window hid the toolbar".

I won't comment here, I'm not a UI designer. Just reporting what I
heard.

> > 
> >> 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).
> > 
> > Well, clients cannot see resources that belong to other clients (object
> > ids are per client, since wl_display.bind was introduced), which means
> > that the "big window list" is server-side only. And obviously, I expect
> > the compositor to obey itself :)
> 
> Yes this list is compositor-only. The compositor can provide window ids 
> that a client can use to put it's own windows above/below, for instance 
> it can have an (unmapped) window that indicates the border between the 
> desktop layer and the window layer, or between the windows and alerts. 
> In addition the clients can use "None" as the other window indicating a 
> maximum raise/lower.

Ok, that's fine (although it's not really exposable in the API).

> > 
> >> 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.
> > 
> > Certainly it must be atomic, but I see this part completely compositor
> > side. Differently from resize, in which you have to prepare a new
> > buffer, there is nothing the client needs to do when the stacking order
> > changes. The buffer is already there, is just a matter of drawing it in
> > a different order.
> 
> I am mostly concerned with using extra windows for contents, such as 
> video players running in a different pixel format. It would be nice if 
> resizes of the frame and player were atomic, and if raising the frame 
> also raised the player atomically. Perhaps there is not a need to merge 
> these but it looks kind of useful.

I see what you mean, but it would be hard to get right with the current
attachment system. IMHO, the simplest way would be to have the GPU do
the colorspace conversion and draw the video to a texture, which is then
drawn client-side to the window.

> > Also, clients should not stop updating a window just because it's not
> > visible. Most of time, it will be visible in some other way (Plasma
> > thumbnails, Compiz Expose, Mutter Activities overview)
> 
> Not sure why you think I was suggesting otherwise here. I was talking 
> about the compositor not making a composite that had only some of the 
> rearrangement of an atomic restacking done.

Don't know, I guessed your use case was suspending updates when covered
by another window, to save power.

> > Do we notify clients of restacks in X11? And do toolkits make anything
> > out of that?
> > (Honest question)
> 
> Yes there is a configure notify. However clients can't do anything about 
> it except know it is done.
> 
> My proposed wayland scheme does not reorder the windows until the client 
> says to do so. The compositor "notify" is to tell the client to do this, 
> thus the client can raise/map other windows as well.

Now I understood what you originally meant: you're splitting the
requests to ensure atomicity.
Still, your "really_restack" request is not atomic, unless you have a
"really_restack_completed" request. At which point you can have the
restack_notify (if restacking is a result of user action,
restack_request don't generate restack_notify), the restack_request
(filtered by compositor policy), and a restack_completed that "thaws"
drawing.

> >> 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.
> > 
> > I perfectly agree, and in fact, I have a wl_shell.restack as part of my
> > "EMWH" branch (github.com/gcampax/wayland/desktop-shell-2). As far as I
> > see it, that's all we need.
> 
> Will look at that, thanks!
> 
> > 1) Focus changes...
> 
> Just like resize and restacking, I would put focus changes under control 
> of the clients. The client can, at any time, set any window of it's own 
> as the focus for any input device (the compositor can ignore this to 
> prevent devious clients). Point-to-type is done by clients setting focus 
> as the pointer moves into the window, click-to-type is done by clients 
> setting the focus on clicks. Note the both implementations can co-exist, 
> and in fact can be decided based on what the user clicks on. In 
> particular it is nice if drag&drop did not change focus in a 
> click-to-type environment.

And how would the compositor know if a "acquire_focus" call was
legitimate or not? Should it just always honor it, and except a
well-behaving client?
I'm afraid we're back to the XSetInputFocus mess, where anyone at
anytime can move the focus around, clients are forced to keyboard grabs
to avoid surprises (like a password typed into a chat that just popped
out). There are paragraphs and paragraphs in the ICCCM dedicated to
moving the focus around, I don't want that again.
In the GIMP case, which the original ICCCM stuff was well suited for, we
can have client-side event redirection, without messing with the global
input focus.

> "Activation" would be done by clients both raising and mapping windows 
> and taking various focuses.

Activation is probably the part of window management that needs more
filtering from the WM, as you don't want random windows popping around,
stealing your focus and covering your screen. Clients should not be
allowed to say more than "please, WM, would you activate me?".

> There would probably need to be activation notify and request calls. To 
> make them match the focus it seems they must also be atomic with all the 
> reorder functions.

Activation notify? Isn't it enough to have keyboard_focus for updating
decorations?

> >> 2. For task managers
> > 
> > Among the three major WMs, KWin is the only one that is keeping the
> > desktop shell in a separate process
> 
> Sorry, I also assume any "task manager" will just be part of the 
> compositor process. The problem is that the user of the "task manager" 
> probably wants an icon in there that says "GIMP" even though there are 
> perhaps 2 image windows that are raised by it. The best way I can see to 
> do this is to have dummy windows that you can also send all the requests 
> and notifys to. GIMP would create this, and requests to raise this dummy 
> window would instead raise all the real ones.

GNOME Shell already groups by pid, and allow for actions that affect the
whole group, without worrying about the group leader window.
In any case, the problem with duplicating the actions client-side is
that you don't have the complete picture and don't know the effects. For
example, let's say you click on "GIMP" and as a result the client asks
to raise both image windows.
What if one of them is an another workspace? In current mutter, this
results in the demands-attention state (which in the shell is translated
to a "GIMP is ready" notification).
Current shell solves this by activating the last window when selecting
an app, but that's a just one possibility. In GNOME Panel, IIRC, there
was an option that brought all windows to the current workspace when
activating a group.

Giovanni

-------------- 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/20110916/bd5abc40/attachment-0001.pgp>