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

[Pekka Paalanen]

On Thu, 20 Dec 2012 14:15:56 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> 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 

Ah right, that is true.

> already has the ability to specify the input region which I think serves 
> the purposes you are thinking of for the bounding box.

Perhaps. (Input region is not in the shell protocol or api, btw.)

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

If you are talking about the protocol here, then yes, for sub-surfaces
I already have a single parent association. Having a sub-surface parent
association excludes any other associations, so this cannot cause
multiple parents to appear in a compositor implementation.

Whether reassigning or removing the sub-surface parent association would
be useful and should be allowed, is still an open question.

I don't understand the comment about a "data structure".

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

I wrote about concepts and the protocol, you reply with implementation
details. I don't see much relevance here.

It seems to me that you have not understood the existing code nor
architecture of Weston at all, even before my sub-surface
implementation, which you obviously have not seen. Your two
paragraphs above are full of factual errors, though I do agree on the
goal of having reusable and simple code.


Thanks,
pq