search for: compstackingupdatemodenon

Displaying 3 results from an estimated 3 matches for "compstackingupdatemodenon".

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...