Oh sh.. it is a "layer".
> + struct weston_layer notification_layer;
This is not good. Please figure out a way so that clients can control
the window stacking without having to copy every idea that a client
needs into the compositor.
Recommendation:
Each surface has a "parent", if it is not null, the compositor keeps
that surface above the parent, by moving it upward if the parent is
moved so the order is always enforced. It never causes a surface to move
downward.
The client is allowed to change the "parent" at any time. This will
cause an upward movement of the reparented surface if the new parent is
not null and is higher than the surface.
Reparents are deferred until a commit on both the old and new parent.
The compositor NEVER raises a window except by a raise command from a
client. This is so the client can create/destroy/reparent any other
surfaces it wants before raising one.
In reality the "parent" stuff is not needed at all, there could just be
a command of "put surface a above surface b" that is deferred until a
commit is done on b. The parent stuff does allow the most common
hierarchy to be communicated to the server, while as long as the parent
can be changed it allows any arrangement a client wants. The parent
hierarchy also allows the connections between surfaces to be known to
panel applications.
This should be figured out first, before you start making "layers" to
try to work around the lack of client-controlled stacking order. I think
you will find that "layers" are unnecessary, or that they can be made a
lot more generic. The main thing a "layer" does is allow a client to
force it's surface to be above surfaces belonging to another client,
which I think is unnecessary and is really just a bug of current work
arounds for window management that does not allow arbitrary client
restacking.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
