[PATCH] [RFC]Shell: Hide panels when compositor has a top fullscreen surface.
zhiwen.wu at linux.intel.com
Sun Feb 19 18:41:19 PST 2012
>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
>Cc: 'Juan Zhao'; Wu, Zhiwen; wayland-devel at lists.freedesktop.org
>Subject: Re: [PATCH] [RFC]Shell: Hide panels when compositor has a top
>> 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
>> 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
>from "regular windows". I think it is annoying that this needs to be done
>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
>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
>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
>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
>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
>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
>that window has had an attach since the last raise, then it fixes the
>order to put it there, and continues searching. Otherwise it leaves it
>attach is done or a timeout happens.
>> 2. "Drag and Drop" click should be treated differently from regular
>> 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.
>the "solution" Windows provides which is very bad.
>The correct solution is: "windows do not raise unless the client requests
>has NOTHING to do with d&d except that d&d is ONE example of how automatic
>If the client starts a d&d it will probably *not* raise the window, but
>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
>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
More information about the wayland-devel