<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> On 02/17/2012 04:55 AM, Bill Spitzak wrote: <blockquote cite="mid:4F3D6D5E.407@gmail.com" type="cite">Juan Zhao wrote: <blockquote type="cite">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. </blockquote> 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. </blockquote> 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: <a href="https://gitorious.org/dataforuse/dataforuse/blobs/master/dictionary.jpg">https://gitorious.org/dataforuse/dataforuse/blobs/master/dictionary.jpg </a> <blockquote cite="mid:4F3D6D5E.407@gmail.com" type="cite">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 </blockquote> 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". ...... <blockquote cite="mid:4F3D6D5E.407@gmail.com" type="cite"> <blockquote type="cite">And this is the current implementation in both compiz, metacity, mutter in linux and even in windows. </blockquote> 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! <blockquote type="cite">We can make it better if the other solution really brings benefits. </blockquote> 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. <blockquote type="cite"> <blockquote type="cite">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. </blockquote> I did not assume that. ~  Just curious why you said I assume this~ </blockquote> 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 <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote> </body> </html>