[PATCH] [RFC]Shell: Hide panels when compositor has a top fullscreen surface.

[Bill Spitzak]

wuzhiwen wrote:
> Hi Bill,
> Thanks for your reply. I summarized my scheme as following:
> 
> 1. Make the panels always atop the top regular window.
>   This means no hiding operation to panels, all things is about stacking
> adjustment. Compositor will check the window status and adjust the stacking
> every time before it repaint the output. 
>   The checking and stacking adjustment could be a hook implemented by shell.
> For example, if we have 2 windows, and make the top one(window_1) to
> fullscreen, panels will be adjusted atop the window_2 and under the
>   Window_1(fullscreen window).

That requires "dialog boxes" and "popups" to be identified and 
differentiated from "regular windows". I think it is annoying that this 
needs to be done but I don't see any other way to get your odd behavior 
of panels atop fullscreen windows to work. Since Wayland certainly 
should allow some behaviors whether or not I like them, it looks like 
such identification is necessary.

Please make sure there is no information about "which window this popup 
is for". That is the start of the Directed Acyclic Graph, which I hope I 
have pointed out is a big problem for all current window managers 
(because it can only work with perfect synchronous update from clients, 
and because stacking rules clients want are enormously complex).

Also, except for not counting as a "the panels go above this", there 
should be no difference in how "popups" and "regular windows" work. In 
particular no stacking rules between them can be enforced.

There is no need for a "hook". The shell has final control over window 
stacking. I propose that the shell keep a simple list of "the order I 
want it". It then progresses from top to bottom finding the first 
mismatch with the compositor. If that window has had an attach since the 
last raise, then it fixes the compositor order to put it there, and 
continues searching. Otherwise it leaves it until an attach is done or a 
timeout happens.

> 2. "Drag and Drop" click should be treated differently from regular click.
>   Agree with you, applications determine how to deal with the click. If
> click triggers a dnd , do not raise the window.

This I hope is just poorly worded, and not what you are actually 
thinking. That is the "solution" Windows provides which is very bad.

The correct solution is: "windows do not raise unless the client 
requests it". It has NOTHING to do with d&d except that d&d is ONE 
example of how automatic raise sucks.

If the client starts a d&d it will probably *not* raise the window, but 
nothing in wayland should force a tie between these in any way.

>   I think the fullscreen app should not assume the stacking status.

That means they cannot put any useful GUI elements in any area that may 
be obscured by a panel, since the user will be unable to click on them. 
This kind of defeats the purpose of fullscreen windows.

I think at least that a fullscreen app should be able to assume the 
panels do not obsucre it if it did a "raise" recently.