spitzak at gmail.com
Wed Sep 14 11:24:24 PDT 2011
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
>> 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
"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
>> 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.
More information about the wayland-devel