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

[wuzhiwen]

>-----Original Message-----
>From:
>wayland-devel-bounces+zhiwen.wu=linux.intel.com at lists.freedesktop.org
>[mailto:wayland-devel-bounces+zhiwen.wu=linux.intel.com at lists.freedesktop.o
>rg] On Behalf Of Bill Spitzak
>Sent: Saturday, February 18, 2012 3:56 AM
>To: wuzhiwen
>Cc: 'Juan Zhao'; Wu, Zhiwen; wayland-devel at lists.freedesktop.org
>Subject: Re: [PATCH] [RFC]Shell: Hide panels when compositor has a top
>fullscreen surface.
>
>
>
>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.

[Wu, Zhiwen] Agree.
>
>>   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.

[Wu, Zhiwen]Agree. But my concern is when a regular window raised atop a
fullscreen one, should panels raise too?
>_______________________________________________
>wayland-devel mailing list
>wayland-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/wayland-devel