I see no reason for extra objects. What I would do is add a "parent" to
the normal surface. If it is NULL then it is a "main" surface. If it
points at another surface then it is a subsurface or a floating window.
The "parent" can be changed arbitrarily. We must be able to change an
existing surface from being a "main" to a "subsurface" to a "floating
window" at any time, so making them different types is not acceptable.
If the parent is another "subsurface" that controls the ordering, in an
obvious manner without any additional api!
FLOATING WINDOWS:
PLEASE consider reusing this code for "floating windows". THEY ARE THE
SAME THING!!! The only difference is that the compositor can insert
other surfaces between floating children and the parent.
This would allow all work done to make subsurfaces not blink and to move
in lock-step also be used for floating windows, which would address a
deficiency in all existing window systems. It will also force the
floating window api to allow the client to be in final control of the
stacking order, a deficiency in all existing window systems.
Conversely floating windows have a lot of stuff figured out for focus
and event handling, like grabs, and cooperation between tasks and
threads. All of this is needed for subwindows so it makes sense to reuse it.
CLIP:
Main windows need clip as well. This is so they can draw edge
decorations that are clipped off when the window is maximized, rather
than having to alter their drawings depending on maximization.
More important surfaces should be able to inverse-clip (the clip is
bigger than the image) for cases where the shell api needs a particular
size but the client knows that a portion is not visible. We need this to
clip off any number of edges less than 4 (for maximize
horizontal/vertical), and to allow subwindows to be used to add the
borders to a main window that is actually smaller than it tells the shell.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
