Window stacking diagram

[Bill Spitzak]

Pekka Paalanen wrote:

> Layers, as they are in Weston today, are purely an implementation
> detail. They are not reflected in any public protocol at all. Therefore
> I don't think we are tied in any way to any "layers" design yet. It's
> good to keep that in mind and avoid tying our hands with it, I agree.

My main concern is that if you add "layers" it will defer attempts to 
really fix window stacking. I would prefer the hard and more important 
problem be done first.

> Any public stacking protocol cannot have references to other clients'
> windows. Juggling the stacking order between windows from different
> clients must be left as a compositor implementation detail.

Yes, in fact all schemes I can think of basically involve "layers" so 
there is going to be something like that. "layers" are used to refer to 
surfaces that don't belong to the client.

In my example where A and B are "normal windows", C is a "panel", and D 
is a "fullscreen window" that normally goes above the panel, I expect C 
will be "in" a "panel layer". A and B have been marked as "always below 
the panel layer", in that an attempt to raise either of them raises all 
surfaces in the panel layer. D is *not* marked in this way, so it can be 
either above or below the panel. So this is not the strict ordering that 
may be implied by the "layer" terminology, but the idea is somewhat there.

There is still a lot of this I have not figured out, however.

> It is a bit unclear when you talk about "Wayland". Stacking in this
> case is quite unrelated to Wayland the core protocol and libwayland-*
> libraries. When we talk about protocol, I would prefer to say wl_shell
> in short for "the public desktop shell protocol", just to be explicit.

Yes of course I mean the shell api, though I am confused by the 
insistence by some other posters here that subwindows are not part of 
the shell api. I do agree with them that it seems the separation of 
wl_surface from wl_shell seems to be an artificial exposure of 
implementation details, in that if I understand this correctly it is 
impossilble to get a surface on-screen unless the shell api is created.

> Quite some time ago there was an idea of some kind of a stacking
> negotiation protocol in wl_shell, foremost to solve the problem of
> "should this window be raised on click" and similar.

The ONLY thing that can decide "should this window be raised on click" 
is the client. DO NOT MAKE THE SHELL RAISE ON CLICK!!!!!

I hope the problem with drag and drop has made this obvious, but 
considering that X and Windows have had this bug for 25 years now I have 
my worries...

It does however look practical to have the shell raise multiple surfaces 
*when and only when the client asks for one of them to be raised*. In 
particular it looks like it is necessary to automatically raise surfaces 
belonging to *other* clients, which is not something a client could do.

> Currently we do
> not have any stacking related protocol. We only have a few window
> types, which only loosely imply something about stacking.

Again my worry is that too many people will think "window types" is 
sufficient and thus not implement a correct stacking protocol.

> The same
> idea applies for keyboard focus, by the way (hm, or maybe it was
> discussed for kbd focus originally?).

Not sure about that. I would like keyboard focus to be completely 
disassociated from window stacking. There should be no requirement that 
the window with keyboard focus be on top, for instance. Clients can 
easily enforce this themselves if it is desired.

> Designing a good re-stacking protocol, which include the "raise or not"
> solution, will be quite a trick.
> 
> My hunch on the matter is some sort of negotiation with atomic
> reassignment of stacking order for all the client's windows. A client
> gets an input event, that gives it a chance to "raise" a subset of its
> windows and arbitrarily reorder all its windows in the same go. By
> "raise" I mean reordering with respect to other clients' windows, which
> I think could be just a boolean, raise or not, since it cannot
> explicitly refer to other clients' objects. I have no idea how this
> protocol should look like, nor if it should have interactions with
> wl_surface.commit behaviour. For clarity and easier debugging, I think
> we might want to avoid simple protocol requests like "put A on top of
> B" since that means the whole protocol history would have to be
> replayed to see what the ordering should be, and do the client and the
> server agree. But on the other hand, a protocol request for "this is
> the ordering of all my windows" raises questions like: is it
> inefficient to send a full list of window references for every
> re-stacking? What if the client does not include all of its windows?

My idea is that the client can set the "parent" of any window to another 
window. If you set a parent the child is immediately raised if it is 
below the parent to just above it. If you raise a parent then the entire 
tree of children is raised if they are below the new parent location, 
keeping them in the current order otherwise.

This is done by single calls to set or clear the parent of each surface. 
So the client can incrementally update the tree. Attempts to make a 
cycle are ignored, or perhaps produce an error. Deleting a parent sets 
the parent of all the children to the deleted parent's parent.

The ABCD sample requires the client to change the tree before raising 
either A or B. But I feel this is the correct trade off, as the tree 
handles a huge majority of real-world situations, without being 
unnecessarily complex.