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

[Bill Spitzak]

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.