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

wuzhiwen zhiwen.wu at linux.intel.com
Thu Feb 16 18:40:58 PST 2012


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). 

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. 

3. For your concern about "some areas of fullscreen window obscured by
panels (It is the case that raised a regular window atop fullscreen one)",
user can un-fullscreen the window firstly and do whatever he want.
  I think the fullscreen app should not assume the stacking status. 

>-----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: Friday, February 17, 2012 4:56 AM
>To: Juan Zhao
>Cc: Wu, Zhiwen; wayland-devel at lists.freedesktop.org
>Subject: Re: [PATCH] [RFC]Shell: Hide panels when compositor has a top
>fullscreen surface.
>
>Juan Zhao wrote:
>
>> If the top regular surface does not occupy the full screen, you can
>> still click on that underlying fullscreen surface to active and raise it.
>> I do not understand why this defeats the whole purpose of letting
>> other surfaces be above that fullscreen surface.
>
>Because it will raise the fullscreen surface, thus obscuring the overlaying
>windows. Which then brings up the question: why did you go through all this
>trouble to allow the overlapping windows when it is impossible to use?
>
>If you really think this is acceptable, then an enormously easier solution
(and the
>one used by Windows) is to simply say that fullscreen windows are always on
top,
>that the situation shown where non-fullscreen ones can be atop it is not
possible.
>This would remove any question about whether panels should be atop or not
and
>remove what I think is a very strange state of the system, and not remove
any
>functionality, since if clicking in the fullscreen window raises it it
makes this
>entire arrangement almost useless (well you can "read" the fullscreen
window
>without it raising, but you are kind of screwed if you want to do anything
as
>simple as move a scrollbar in it).
>
>> And this is the current implementation in both compiz, metacity,
>> mutter in linux and even in windows.
>
>Yes, they are WRONG.
>
>You should be able to push a button or click in a lower window without
raising it.
>These idiots are finally realizing it because "drag and drop does not work
right"
>but it has been true for 15 years or more now. Old
>X11 window managers did it right, which is why people are resisting the new
>ones. You could select text and fire actions in background windows, which
is
>impossible in modern Linux window managers, impossible in Windows, and
>impossible in OS/X.
>
>Linux window managers are completely broken. Windows actually (at a low
>level) does it right, in that drag & drop does not raise the window you
drag from.
>Thus the raise is deferred until after the application handles the click
>(unfortunatly there does not appear to be any way to avoid the raise except
by
>interacting with the d&d api). OS/X appears to have the same bug as Linux.
>
>What really annoys me is that this bug is so *trivial* to solve. The
application
>does a "raise()" call *after* it looks at the click and decides whether it
should
>cause a raise or not. It does not remove click-to-raise in any way!
>
>> We can make it better if the other solution really brings benefits.
>
>It brings HUGE benefits: it makes overlapping windows *useful*.
>
>Right now overlapping windows are useless because you cannot interact with
>windows that art not on top, so there is no reason to ever overlap them.
This is
>a *BUG* on Windows, OS/X, and every X11 window manager for about 15 years
>now. It has made it impossible to implement any program with overlapping
>windows, which is why you see tiled api's in full-screen windows in every
modern
>application. It is to work around this bug by making sure no windows
overlap.
>
>>> In addition you seem to be assuming that clicks in "inactive" windows
>>> should do nothing. There are a LOT of people who disagree and Wayland
>>> should certainly not actively prevent this.
>> I did not assume that. ~  Just curious why you said I assume this~
>
>Because you say right above that "clicks in the lower window raise it".
>This means the click has a different behavior for an "inactive" window.
>_______________________________________________
>wayland-devel mailing list
>wayland-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/wayland-devel



More information about the wayland-devel mailing list