GNOME Bugzilla – Bug 571067
Exit overview on panel click (?)
Last modified: 2011-03-19 17:31:22 UTC
When you are in the overlay, you can click on the actions menu, pop up the menu, select an item, except you can't see any of this happening. Simple thing to do would be to disable the button in the overlay. Making the menu work in the overlay would be a little tricky... in theory we could reparent the window actor out of the hidden window group.
It's a general problem - note you can't get the NM context menu either. Maybe we should have a visual effect on the panel showing it's disabled?
While I agree that it's similar, it's not the same, because your status menu *does* come up in the overlay, and does stuff - you can, for great fun - lock the screen, say. The status icons do nothing (which actually suprised me ... not sure the mechanism resulting in thta.)
Created attachment 128418 [details] [review] Bug 571067 - Add press() method to button, bugfixes Button now supports more explicit state management through the previously existing release() method as well as a new press() method. The idea is that if external code wants to create a bidirectional relationship between the button press state and some external state, it can do that using both release and press. We also fix a typo which caused staysPressed to not be used.
Created attachment 128419 [details] [review] Bug 571067 - Hide overlay if any area on panel is clicked Ideally, we'd support most panel functionality when in the overlay mode. However for technical reasons that's a bit complex to do. For now we simply make any click on the panel drop out of overlay mode. Also, this patch changes the way the overlay button works to enforce a pressed state when the overlay is active, regardless of how it was initiated (e.g. via the Windows key as well).
Button patch looks fine though the whole staysPressed thing seems like a bit of hack. Might be cleaner to do it more like GtkToggleButton where the appearance is the combination of three independent things: 'active' boolean (toggle state) 'hovering' boolean (mouse over button) 'mousedown' boolean But not important unless we get some more complex usages. + panel.overlayConnect(overlay); Any reason the panel can just access Main.overlay in its constructor? It seems we could have a lot of connect-a-to-b functions. + this.emit('visible', true); The two patterns I like are either: this.emit('visibility-changed') then check overlay.visible ... I think this is the most resistant pattern to reentrancy problems. Or alternatively separate 'shown' 'hidden' signals. + // Not initially added to a parent. Wouldn't it be a bit simpler to add it and show/hide it as appropriate? (Then you wouldn't have to have inputBox.added, you could just have if (Main.overlay.visible) this._inputBox.show() else: this._inputBox.hide() + this._inputBox = new Clutter.Rectangle({ reactive: true, Can we have a better name, maybe '_trapInputBox' ? + this._inputBox.connect('button-press-event', function (b, event) { Marginally more consistent to do on release?
*** Bug 576412 has been marked as a duplicate of this bug. ***
Making private to test privacy in my patchqueue script. Will make it public again in a second.
Making public again
Comment on attachment 128418 [details] [review] Bug 571067 - Add press() method to button, bugfixes Marking patch obsolete as the functionality was moved to ST in 2f1ca7bf2.
Comment on attachment 128419 [details] [review] Bug 571067 - Hide overlay if any area on panel is clicked i don't think we want this functinoality, but the patch was marked obsolete only by accident
Probably ok to close this since we're removing status icons from shell chrome?
Marking obsolete because all of the panel is now supposed to work in the overview (the exception being network in some cases).