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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
