[compiz] window stacking bug #1

[Bogdan Butnaru]

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 — bogdanb at gmail.com
"I think I am a fallen star, I should wish on myself." – O.