Window stacking

[Bill Spitzak]

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.

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

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

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

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

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

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

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

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.

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

> I guess you mean the equivalent of the "group leader" window in X
> terminology. We could allow to map a window transient to an unmapped
> one, or we could have toolkits map a transparent window with no input
> shapes. In either case, I don't see a need to for special "application"
> windows (also, application matching is usually done with WM_CLASS and
> pid, not window groups).

In my proposal there is no indication of the window grouping at all. The 
extra window just "exists" so that the task manager or whatever can show 
an entry for it. What the client does when told to raise/activate/etc 
the dummy window is up to the client only.