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

[Juan Zhao]

  On 02/17/2012 04:55 AM, Bill Spitzak wrote:
> 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. 
NO, thinking of this situation: when I'm using fullscreen browser and 
need the dictionary to look up some word. The non-fullscreen dictionary 
should be on top of that fullscreen browser. Here is a picture in windows:
https://gitorious.org/dataforuse/dataforuse/blobs/master/dictionary.jpg 
<https://gitorious.org/dataforuse/dataforuse/blobs/master/dictionary.jpg>

> 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)."clicking the window" will raise it
You opposed ""clicking the window" will raise it"?
As a user, how to raise the applications they want to use when they are 
obscured partially by others? If I'm the user, I will be confused by 
"even I click it, it still can not fully show".

......

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120217/b2e2b64f/attachment.htm>