GNOME Bugzilla – Bug 571827
hide panel when screensaver is active
Last modified: 2009-03-23 13:37:53 UTC
the top panel doesn't show when the screensaver is running and so that locking the screen works
Created attachment 128769 [details] [review] patch for this bug View for ActiveChanged (org.gnome.ScreenSaver) signal.
Hey, ok, two issues: 1) BigBox is used for things other than the panel, so the code can't go there. What we want is for something in panel.js to get the signal, and then just hide() the panel actor 2) Listening to the screensaver signal would solve the problem for the screensaver, but the right long-term solution is for the panel to hide when *any* window goes fullscreen. (Eg, if you hit F11 in firefox or evince or something.) This probably involves having metacity emit some sort of signal in that case, which the javascript code would catch and do the right thing with.
Created attachment 128911 [details] [review] corrected patch Add show/hide method to BigBox. Catch active-window-changed signal (libwnck) and state-changed for active window.
Hm... ok, first, you don't need to add show/hide to BigBox; it inherits from ClutterActor, and ClutterActor already has show/hide methods. So you can just remove that part of the patch, and the "me._box.hide ()"/"show" will still work. Using libwnck feels like too much of a hack here; metacity itself already has all of that information internally; libwnck basically works by spying on what metacity is doing, but that's just extra work in this case; we should have metacity telling the plugin what it's doing directly. The right thing to do is to patch metacity-clutter, to have MetaScreen emit a signal when a window goes fullscreen or stops being fullscreen. (You should also use gboolean rather than a 0/1 int for the signal argument.) Then you can connect to that signal directly (on global.screen) from panel.js and not need to modify anything in the shell/*.c code. "screensaver activating" is just a special case of "window goes fullscreen", so you don't need to watch for *both* events, just the latter.
Created attachment 129284 [details] [review] metacity-patch Add fullscreen property to window
Created attachment 129285 [details] [review] corrected patch Catch notify::fullscreen signal. Work fine with fullscreen application. But doesn't work with screensaver(Should I watch for "screensaver activating" event?).
OK, after some discussion with Owen yesterday I think I'm going to finish this one up myself. We're still somewhat figuring out exactly the right metacity fix... The basic rule (I *think*) is that the panel should be visible unless any window in the window stack is in META_LAYER_FULLSCREEN, *or* any window in META_LAYER_OVERRIDE_REDIRECT covers the area where the panel is (which can probably be handwaved to "any window in META_LAYER_OVERRIDE_REDIRECT has the fullscreen flag set", meaning basically "the screensaver window"). While talking about this yesterday, I said "the topmost window" several times, but that's wrong, because the topmost window might be a GtkMenu of a fullscreen window, in which case it would be META_LAYER_OVERRIDE_REDIRECT (but not covering the panel), and you need to look another window down the stack to see that there's a META_LAYER_FULLSCREEN window there. To make this work, we need to break an abstraction barrier in one direction or the other: either gnome-shell needs to analyze the window stacking to decide whether or not it should display the panel, or else mutter needs to know that gnome-shell has a fake _NET_WM_TYPE_DOCK window that it wants to be told whether or not to show. I guess actually mutter already does know that gnome-shell has a fake panel to some extent, because of the builtin_struts thing. So maybe we should just make this more explicit. Eg, mutter_plugin_add_panel(ClutterActor *), which would set up struts and add an actor to the mutter window_group which mutter would then stack appropriately whenever clutter_cmp_sync_stack() was called (which would then even let us have tooltips and stuff get stacked above the window when appropriate). We'd have to reparent the panel out of the mutter window_group when going into the overlay, but that's pretty easy. (Or maybe we'd have a similar-looking-but-distinct panel for the overlay, to address the using-panel-applets-in-the-overlay problem.) Alternatively, we could just add MetaScreen:show-panel, and have stack.c set that. Easy, but totally unlikely to ever be accepted upstream.
*** Bug 575076 has been marked as a duplicate of this bug. ***
owen, thoughts on comment #7?
There's something of a "three's a crowd" problem - we need to sync up what the metacity core is doing, what compositor/mutter is doing, and what we're doing in gnome-shell. To me, the odd one out here is compositor/mutter - as much as possible, I think it should just be handling creating and updating a ClutterActor for the window, and leave the manipulation of the scene graph to us. (Even the current amount of manipulation it does of the scene graph makes doing stuff like using the original window actors in the overlay instead of clones hard.) For that reason - I don't like mutter_plugin_add_panel(), because it's ceding policy not to the metacity core, but to compositor/mutter. But MetaScreen::show-panel doesn't seem sufficiently generic. What if we just fed a signal through to the JS code when stacking changes, and have the JS code put the panel actor into the window group at the appropriate place in the stacking order?
Created attachment 130552 [details] [review] Add a MetaScreen:restacked signal and expose MetaWindow.layer. for #571827 This is the metacity-clutter part.
Created attachment 130553 [details] [review] Initial attempt at panel stacking. Does not work with screensaver The need to fiddle with both the panel actor and the stage_input_area complicates things. Since we can't (currently) set a non-rectangular input area, that means we can't allow a window to partially overlap the panel, because we can't set the input area to cope with that. So if a window tries to just partially overlap the panel, we won't let it, but if it completely covers it, then we will. (Of course, we can just hide the panel in this case rather than bothering to actually stack it.) This patch deals with the fullscreen window case, but not the screensaver. To do that, we'll need to check for LAYEROVERRIDEREDIRECT windows too, and check their size, but this gets tricky again, because the window might be created at less-than-fullscreen size, and then resized *after* we get the restacked signal. (Or at least, the MutterWindow might not reflect the resizing until after we've processed the restacking.) So we'd have to track the size of any override-redirect windows... Also, it currently doesn't deal with going into the overlay correctly in all cases, but we need to figure out what we want to do with the panel in the overlay anyway (to, eg, make the user menu either work, or else be disabled).
Metacity patch looks good, except for the fact that the enums ended up as StackLayer.LAYEROVERRIDEREDIRECT, intead of StackLayer.OVERRIDE_REDIRRECT etc. Colin is going to look into that, then I'll push the patch. gnome-shell patch looks fine as well. Is the avoidance of Lang.bind in: + global.screen.connect('restacked', + function() { + me._restacked(); + }); just to keep consistency with surrounding code?
I wrote a log entry and pushed the metacity-clutter patch to our repository: commit fca80915fae624fce95386956a5a30d73eeff3b7 Author: Dan Winship <danw@gnome.org> Date: Thu Mar 12 17:07:27 2009 -0400 Add a MetaScreen:restacked signal and expose MetaWindow.layer Expose restacking and a window's stack layer to allow a compositor to insert elements into the window stack in the right location. (See Bug 571827 – hide panel when screensaver is active) src/core/stack.h src/include/common.h: Move MetaStackLayer to a public header. src/core/screen.c src/core/screen-private.h src/core/stack.c: Add a ::restacked signal emitted after we finish restracking. src/core/window.h src/include/window.h: Add meta_window_get_layer()
Created attachment 130914 [details] [review] Notify the compositor of new windows slightly sooner. In particular, make it so that we call meta_compositor_add_window() on a new window before calling meta_compositor_sync_stack() to position it. The list returned by mutter_plugin_get_windows() is only updated by sync_stack(), but sync_stack() only pays attention to windows that add_window() has already been called on. So without this change, a newly-mapped window will not be returned by mutter_plugin_get_windows() until after the *next* restacking.
Created attachment 130915 [details] [review] Fix panel stacking with respect to fullscreen windows and screensaver Because we can't set the stage input area to a non-rectangular shape, we don't allow the panel to be partially overlapped; it is always either on top, or else completely hidden.
(In reply to comment #13) > gnome-shell patch looks fine as well. Is the avoidance of Lang.bind > just to keep consistency with surrounding code? Yes. (In reply to comment #15) > Notify the compositor of new windows slightly sooner. Of course it's possible this will end up having unforseen side effects... but it seemed like the sanest way to deal with this problem. This should probably go upstream.
Hmm, are Meta.StackLayer.OVERRIDE_REDIRECT windows always at the top of the stack? Override-redirect windows don't have to be above everything. Though practically speaking it doesn't matter much. I can't see having an override window overlapping the panel beneath the panel being common. + // We want to be visible unless there is a window with layer + // FULLSCREEN. (We can't set a non-rectangular + // stage_input_area, so we don't let windows overlap us + // partially.). @windows is sorted bottom to top. Looks like this comment might need updating for the override-redirect addition. The metacity change seems like a reasonable thing to try. I'll push it into our tree and file into openedhand bugzilla.
Metacity patch applied and filed upstream as: http://bugzilla.openedhand.com/show_bug.cgi?id=1512
(In reply to comment #18) > Hmm, are Meta.StackLayer.OVERRIDE_REDIRECT windows always at the top of the > stack? That appears to be mutter's assumption. If we/they find something where that doesn't work in the future, then any changes to the mutter stacking code will probably break panel.js's stacking code too. > Looks like this comment might need updating for the override-redirect addition. Yup. Updated that and pushed the patch. I'd been trying to find a nice solution for the panel-in-overlay-mode problem too, but I'm going to file a separate bug for that.