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