On Wed, 19 Dec 2012 15:52:03 -0800 Bill Spitzak <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
