Hello! I'm trying to find where to send a bug report/fix, and this mailing list is the best I found.
I noticed several problems in how Compiz handles full-screen windows*, and I hacked a bit around the source to try to find their source. (*: I use this pretty much as a replacement for full-screen, all the time.) The first two are together below, because they seem caused by the same code. For the third I'll send another email. In all cases below, full-screen windows are NOT un-redirected. * Problem one Say the topmost window is non-full-screen and the window _immediately_ below it is a full-screen window (so the two are the topmost windows). In this case, if the user moves the normal, top-most window by dragging its title-bar, the window is immediately hidden below the full-screen one. (The move can be continued correctly, but without the benefit of actually seeing the window, unless the full-screen one is semi-transparent.) However, if the window is moved using alt+drag outside the title-bar, everything is normal. Note that this doesn't happen if there are at least two normal windows above the full-screen window. * Problem two: If the topmost window is a full-screen window, the widget layer is displayed below it when the user presses the "show widgets" shortcut. This means the widgets are invisible, unless the full-screen window is transparent. (Note that the window is correctly "shaded". **** I took a look at the source, and the problem seems to be in src/window.h, function raiseWindow(). The function uses findSiblingBelow (w, FALSE) to position the window it's called on, where the FALSE parameter means that the sibling (on top of which the window is moved) cannot be a full-screen window. The result is that if the topmost window is full-screen, calling raiseWindow() on a window will leave it hidden. In the case of problem one, here are the two scenarios: When the user initiates moving a window using the Alt+drag combination, compiz calls (among other things): updateWindowAttributes(w,CompStackingUpdateModeAboveFullscreen) followed by updateWindowAttributes(w,CompStackingUpdateModeNone) However, when the user initiates a window move by dragging its title bar, the calls (excerpted) are: updateWindowAttributes(w, CompStackingUpdateModeAboveFullscreen) raiseWindow(w) updateWindowAttributes(w, CompStackingUpdateModeNone) In this case, the first call puts the window at the very top, and then raiseWindow actually moves it downwards, below the full-screen one. I believe the raiseWindow is caused by the (standard) behavior of raising a window on click. I don't know why it doesn't happen for clicks below the title-bar, though, and I couldn't find where it originates. For the second problem, it seems the Widget plugin calls raiseWindow to put the widget windows (I use screenlets) on top of the screen. Which of course can't happen if the topmost window is full-screen, because of how raiseWindow is defined. *** I'm not sure exactly why raiseWindow is defined the way it is now. Unless there's a very good reason for it, I propose changing the second parameter of findSiblingBelow to TRUE. This would automatically fix the two issues I mentioned above. However, if there is a really good reason why raiseWindow should stack below topmost full-screen windows, we need to find solutions for the other two problems. What do you think? -- Bogdan Butnaru — [EMAIL PROTECTED] "I think I am a fallen star, I should wish on myself." – O. _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz