GNOME Bugzilla – Bug 611379
top panel disappears if a transparent window goes over it
Last modified: 2010-03-01 03:24:58 UTC
Created attachment 154889 [details] simple python test case Cheese flash is currently implemented using a white popup window the fills the whole screen. When it is fired the window opacity suddenly goes to 1 and gradually fades out until it's hidden when opacity reaches a minimum value. While the window is fading out gnome-shell top panel disappears while other windows are correctly rendered. We could probably add some workaround in cheese but I think we're exposing a gnome-shell bug that should be fixed. Attaching a python snipped that reproduces the issue (it's first thing I ever wrote in python, so don't criticize if there's something ugly :-P)
(In reply to comment #0) > Created an attachment (id=154889) [details] > simple python test case > > Cheese flash is currently implemented using a white popup window the fills the > whole screen. When it is fired the window opacity suddenly goes to 1 and > gradually fades out until it's hidden when opacity reaches a minimum value. > > While the window is fading out gnome-shell top panel disappears while other > windows are correctly rendered. > > We could probably add some workaround in cheese but I think we're exposing a > gnome-shell bug that should be fixed. > > Attaching a python snipped that reproduces the issue (it's first thing I ever > wrote in python, so don't criticize if there's something ugly :-P) I tried your test case ... the top panel goes away when there is a fullscreen window on the primary monitor (i.e you don't want it to be around while watching a movie or playing a fullscreen game). So what happens here is that you create a fullscreen window which causes the panel to be hidden. As long as the fullscreen window is open (i.e independent of its opacity) the panel won't be displayed. Well your window is not really a fullscreen window but a screen sized one .. this should be bug 588234 (i.e mutter assumes that a screen sized window is intended to be fullscreen and tells us "this is a fullscreen window" so we hide the top panel).
(In reply to comment #1) > Well your window is not really a fullscreen window but a screen sized one .. Exactly we had a fullscreen window once but it caused some issue with mutter (bug 598902). > this should be bug 588234 (i.e mutter assumes that a screen sized window is > intended to be fullscreen and tells us "this is a fullscreen window" so we hide > the top panel). Indeed you're right, if I do: self.window.resize(geom.width-1, geom.height-1) The top panel is visible again but it goes on top of the transparent window. I'm not sure this is a desired behavior either though. If you add the following to the snippet self.window.set_skip_taskbar_hint (True) self.window.set_skip_pager_hint (True) self.window.set_decorated (False) self.window.set_keep_above (True) The window is trying everything to tell the window manager to let it do what it wants, particularly it's politely asking to be kept above everything. But the top panel ignores it and goes on above it. Is this a desired behavior?
(In reply to comment #2) > (In reply to comment #1) > > Well your window is not really a fullscreen window but a screen sized one .. > > Exactly we had a fullscreen window once but it caused some issue with mutter > (bug 598902). > > > this should be bug 588234 (i.e mutter assumes that a screen sized window is > > intended to be fullscreen and tells us "this is a fullscreen window" so we hide > > the top panel). > > Indeed you're right, if I do: > self.window.resize(geom.width-1, geom.height-1) > The top panel is visible again but it goes on top of the transparent window. > I'm not sure this is a desired behavior either though. > > If you add the following to the snippet > self.window.set_skip_taskbar_hint (True) > self.window.set_skip_pager_hint (True) > self.window.set_decorated (False) > self.window.set_keep_above (True) > > The window is trying everything to tell the window manager to let it do what it > wants, particularly it's politely asking to be kept above everything. But the > top panel ignores it and goes on above it. Is this a desired behavior? You are right there is no way (that I am aware off) for a window to force itself to be above the panel (other than messing with the COW directly but this is rather ugly (have not tried if this actually works)).
(In reply to comment #2) > Indeed you're right, if I do: > self.window.resize(geom.width-1, geom.height-1) > The top panel is visible again but it goes on top of the transparent window. > I'm not sure this is a desired behavior either though. It is. Only fullscreen windows are allowed to "cover" the panel (unfortunately, "cover" is technically wrong as the panel is hidden but remains on top of the window). > If you add the following to the snippet > self.window.set_skip_taskbar_hint (True) > self.window.set_skip_pager_hint (True) > self.window.set_decorated (False) > self.window.set_keep_above (True) > > The window is trying everything to tell the window manager to let it do what it > wants, particularly it's politely asking to be kept above everything. None of these hints is relevant to the panel - no taskbar, no pager. You may have a point with keep-above - but note that the spec does not define a stacking order for DOCK_TYPE and STATE_ABOVE[1] I'd even guess that the current gnome-panel/metacity behavior is due to not special-casing dock-type windows here (after all, gnome-panel is just a window with special properties). In gnome-shell the panel is not a window and faking it to match gnome-panel's behavior in corner cases is IMO not worth the effort. > But the top panel ignores it and goes on above it. Is this a desired behavior? In my opinion it is - the only legitimate way to have a window appear above the panel is by setting the fullscreen hint. With all that said, our current treatment of fullscreen windows does not work well for transparent windows, so we should probably change the way we handle those. [1] http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER
this is another symptom of the fact that the panel is not actually a window *** This bug has been marked as a duplicate of bug 582653 ***