how to handling panel and popup windows in fullscreen support?

[Bill Spitzak]

Juan Zhao wrote:
>   Hi krh,
>     We thinked over how to handling panel and popup windows in 
> fullscreen support. Just would like to get your suggestion and decision 
> here.

I will try to describe the steps in my scheme where the clients have 
control over their own window stacking. The "raise" command contains a 
list of windows indicating the desired sorting order, and optionally a 
single window id from this list that is the one that should be raised 
above all others. This is shown as [A,B,C],D for A,B,C in the list from 
bottom to top and D as the single window id.

>   These three pictures demostrate fullscreen cases we need to implement:
>   fullscreen window on the top: The panels will be hidden
>   https://gitorious.org/dataforuse/dataforuse/blobs/master/fullscreen.png

- The client requests full-screen for surface W.
- The compositor sends configure request for the correct size.
- Client sends raise [W],W.
- Client renders and attaches W.
- Compositor now re-composites the screen, with W atop the panels

>   un-fullscreen window over fullscreen window: The panels will be shown
>   https://gitorious.org/dataforuse/dataforuse/blobs/master/nFoverF.png

Note that I think the indicated behavior is not what users want. It will 
cause unavoidable obscuring of a portion of the full-screen window. 
However it can be supported, while still allowing a compositor to work 
the way I think it should:

- Client creates any of those panels A,B,C that don't exist yet.
- The client sends raise [A,B,C],A (but NOT of the full-screen window).
- Client renders and attaches A,B,C
- After last attach, compositor re-composites the screen. Since the 
full-screen window was not part of the last raise command, it decides to 
move it below the panels.

>   Popup window over fullscreen window: panels will be hidden
>   https://gitorious.org/dataforuse/dataforuse/blobs/master/PoverF.png

- Client creates the panel P if it does not exist yet
- Client sends raise [W,P],W
- Client renders and attaches W and P (it just does a reattach if W does 
not have to change)
- After last attach, compositor re-composites the screen. Since the 
full-screen window was raised by the last raise command, it remains 
above the panels.

Also you need to figure out what happens in state #2 if the fullscreen 
window decides to popup a panel but not raise. I see it happening this way:

- Client creates the panel P
- Client sends raise [W,P],None
- Client renders and attaches W and P.
- After last attach, compositor re-composites the screen. Since 
full-screen W was not raised it stays below the panels.

>   To handling panels, we are thinking about three methods:

The implementation I am thinking of has two double-linked lists of 
surfaces (ie the surface in the compositor has 4 pointers for next/prev 
in each list).

One list is the current compositing list.

Another list is the "desired" list. This is the order you would get if 
all the pending attaches due to raise commands were done. Raise commands 
work in a rather brute-force method: they search in the correct 
direction from the current location and insert the surface at that point 
(not moving it if the insertion point is not found).

The current compositing list is updated by searching down both of them 
for the top-most mismatch. If the surface that should be at that point 
has been attached then it is moved to that point in the compositing list 
and the updating continues. Otherwise the updating stops until more 
attach commands come in.