On Wed, 2007-11-21 at 22:05 +0100, Bogdan Butnaru wrote:> 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?
raiseWindow should probably be allowed to stack above fullscreen
windows. I'm not sure why it's not doing that right now.
I'm not sure what cases we have where we don't want to allow a window to
be stacked above fullscreen windows but for a window that is not a
transient of the fullscreen window to be stacked above it, the
fullscreen window must first be lowered below the dock-window layer
(e.g. gnome-panel) and you don't want that to happen unless it really
makes sense.
The current stacking code is pretty error prune and I've been thinking
about replacing it with some less complex code that validates the
complete stack of windows every time a stacking change need to be made.
It will be easier to handle all these special cases for fullscreen
windows once this gets done. However, I prefer to wait with this until
we have a proper object system in place.
-David