GNOME Bugzilla – Bug 698938
volume: respond to the volume keys when the menu is open
Last modified: 2013-08-21 18:21:29 UTC
The volume hardware keys cannot be used with the volume menu is open.
Created attachment 242547 [details] [review] volume: respond to the volume keys when the menu is open
Created attachment 242559 [details] [review] grabHelper: Keep the current keybindingMode if not specified This allows keybindings to continue to work when shell menus are up. -- I prefer this more general fix. Hopefully it doesn't break anything...
*** Bug 698868 has been marked as a duplicate of this bug. ***
Review of attachment 242547 [details] [review]: I agree with Rui we want a general fix rather than hardcoding some keybindings - we just got rid of the hacks we were doing let's not go back there (also: it doesn't make much sense, but it *is* possible to reassign the volume keys for other actions using the Shortcuts panel).
Comment on attachment 242547 [details] [review] volume: respond to the volume keys when the menu is open A more general approach would appear to be a good idea, although there are some issues with (for example) attempting to use alt-tab when a menu is open. The first patch would also need further work to make sure any customised shortcuts still work.
Review of attachment 242559 [details] [review]: No, this is wrong as well. Keybindings like volume and screencasting are ok when a menu is open, others are not. In particular switchers like alt-tab/ctrl-alt-tab are completely broken. In my opinion, the correct approach is to add a different keybinding mode for top bar popups (or possibly different modes for app menu, date menu and status-area-that-will-probably-be-a-single-menu-soon-anyway) and mark appropriate keybindings accordingly in g-s-d.
(In reply to comment #6) > (or possibly different modes for app menu, date menu and > status-area-that-will-probably-be-a-single-menu-soon-anyway) This with bug 686756 in mind.
Created attachment 242580 [details] [review] popupMenu: Allow setting grabHelper params for PopupMenuManager Currently all keybindings are disabled while some popup menu is open. However some keybindings may still be useful in some cases, so expose GrabHelper's modal params parameter to allow specifying a keybinding mode for particular menus.
Created attachment 242581 [details] [review] panel: Add keybinding mode for top bar popups and use it Allow some keybindings to still work while a top bar menu is open by assigning it a keybinding mode.
Review of attachment 242580 [details] [review]: OK.
Review of attachment 242581 [details] [review]: OK.
Attachment 242580 [details] pushed as 5c40307 - popupMenu: Allow setting grabHelper params for PopupMenuManager Attachment 242581 [details] pushed as 4a5ff5d - panel: Add keybinding mode for top bar popups and use it
*** Bug 699425 has been marked as a duplicate of this bug. ***
This seems to have stopped working again with the new combined system menu. The volume keys don't function when the menu is open or when the overview is active.
Are you using jhbuild in an existing session? The API for grabbing keys between gnome-shell / gnome-settings-daemon, so they don't work at all.
This seems to work fine in the latest gnome-ostree image, so it may well have been some other issue to do with key grabbing when I first tested it.
Likely using incompatible mutter/gnome-settings-daemon versions as suggested by Jasper in comment #15.