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
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
