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

[Pekka Paalanen]

On Wed, 19 Dec 2012 15:52:03 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> This need to make a tree of transform inheritances is a good indication 
> that the subsurfaces will need to be done with a "parent" pointer, as I 
> proposed. A list does not contain this information and would prevent 
> recursive reuse of any subsurface code to make another subsurface.

By coincidence, I've actually had a parent pointer in struct
weston_subsurface from the very beginning.

> It is not clear why the parent is part of the matrix rather than part of 
> the surface. Technically it is equivalent, but I suspect the parent is 
> going to be used for plenty of other operations that do not look at the 
> matrix.

It's just a generic surface transformation inheritance mechanism,
that can be used equally well by both sub-surfaces and whatever
stick-to-parent relations any shells may need.

> I also still really really believe that there should be little to no 
> difference between these popup surfaces and subsurfaces. Really the only 
> difference is whether the shell can insert other surfaces between them. 
> Duplicating all this work for both popups and subsurfaces is wasteful. 
> As popup surfaces seem much further along, I think the best approach is 
> to modify them so they work as subsurfaces as well.

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.

If we implement tooltips and whatnot as sub-surfaces, then an extruding
tooltip will make the parent _window_ larger. This can have effects on
window management. Most obviously it would screw up tiling window
managers, which would see that the window just changed size instead of
popping up a tooltip (do tiling wms support tooltips? let's assume they
do, I never used one).

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.

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.

One might argue, that we need to reflect the concepts better in the
protocol by introducing an additional wl_window object, which would
"contain" one or more wl_surface objects, and then write all
window-like operations for wl_window objects, instead of wl_surface
like it is now. There are a couple of downsides to that approach:
- Existing protocol is heavily built around wl_surface, and introducing
  a wl_window would break almost everything of shell protocols. As we
  have promised to maintain existing protocols, this is not feasible at
  this time. However, the issue should be reconsidered if the
  need to replace wl_shell interface arises.
- Using a wl_window in shell operations makes sub-surface support more
  or less mandatory, so it will be inconvenient to make it optional.
  Should it be optional is another matter.


Thanks,
pq