[PATCH weston 4/4] compositor: popup inherits surface transformation

[Bill Spitzak]

Pekka Paalanen wrote:

> No, I don't think it will work. The set of surfaces, which is a main
> surface (parent) and its sub-surfaces, forms a single solid window for
> all window management purposes. The bounding box of the whole set
> becomes the size of the window.

I am not very clear on what use this bounding box is. It contains the 
"shadow" (and also the "edges" which I have tried to explain but seem to 
be unable to). In general this is useless for window management because 
the user does not think of those as parts of the window. The shell api 
already has the ability to specify the input region which I think serves 
the purposes you are thinking of for the bounding box.

In any case it would be trivial for the "stuck to the parent" bit to be 
part of the rules for deciding what is merged to produce the bounding box.

> Conceptually I see it like this: zero or more sub-surfaces with one main
> surface forms a window. A window is the entity managed at window
> manager level, and therefore a window is what can be a top-level
> window, tooltip, menu, etc. So yes, we may need another shell
> internal concept of "window groups" to ease stacking management of e.g.
> window+menus+tooltips.

The window groping can be completely controlled with a "parent" pointer. 
All windows that are linked by parent pointers are a "group". This 
avoids adding yet another data structure to wayland and also matches the 
most common usage of floating windows. The big difference from X and 
Windows is that it is officially stated that the client can alter the 
parent pointer at any time, which avoids any needs for attempting to 
solve complex stacking issues using layers and groups or by having to 
support more than one "parent".

> On the protocol level, these concepts are built on the wl_surface
> object, which can form a part of a window (by being a sub-surface), or
> the base object of a window (the main surface, or "parent"). The base
> object can then be associated with meanings like top-level and tooltip
> in the shell level of the protocol.

As far as I can tell the shell is responsible for making the composite. 
The sample shell is already doing elaborate work on clipping out the 
portions of lower surfaces that it knows are not visible. This code can 
be reused for subsurfaces. This is the main reason I do not think there 
should be any difference between subsurfaces and floating windows.

As I see it the shell will use the parent pointers, whether surfaces are 
subsurfaces or floating or "below" subsurfaces, and the history of 
"raise" requests for surfaces, to figure out a single list of every 
single surface in stacking order. Then the compositor can draw this 
efficiently without having to worry about whether things are subsurfaces 
or not.