Displaying 3 results from an estimated 3 matches for "compstackingupdatemodenone".
2007 Nov 21
1
window stacking bug #1
...w
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...
2007 Nov 21
0
window stacking bug #3
...dow*,
int). At the end (line 71 in my version) there's a call to
updateWindowAttributes (w, CompStackingUpdateModeNormal)
However, changing from full-screen to non-full-screen should not
change the stacking. So I believe the call should be changed to:
updateWindowAttributes (w, CompStackingUpdateModeNone)
I tried it, and the stacking works correctly.
-- Bogdan Butnaru ? bogdanb at gmail.com
"I think I am a fallen star, I should wish on myself." ? O.
PS. Is this really the right place to send these mails?
2007 Nov 21
0
window stacking bug #2
..., Compiz calls
updateWindowAttributes() on newly-created windows (window.c), with the
stackingMode argument set to CompStackingUpdateModeInitialMap. This
function is supposed to set the window's (initial) stacking, among
other things. For instance, at one point it runs:
if (stackingMode != CompStackingUpdateModeNone)
{
Bool aboveFs;
aboveFs = (stackingMode == CompStackingUpdateModeAboveFullscreen);
mask |= addWindowStackChanges (w, &xwc, findSiblingBelow (w, aboveFs));
}
which raises the given window on top of everything if the stacking
mode is CompStackingUpdateModeAboveFullscreen....