GNOME Bugzilla – Bug 665547
overlay should respect mutter overlay_key setting
Last modified: 2012-11-17 02:05:15 UTC
I have /org/gnome/mutter/general/overlay_key set to "Control_R" because I need the left windows key for my emacs setup. Anyway, the problem is that if I enter overlay mode by hitting "Control_R", I cannot exit overlay mode by hitting "Control_R" again. I have to either hit Escape or (and this is the buggy part, IMO) the left windows key. Gnome-shell should respect the overlay_key setting and use the same key to exit overlay mode that was used to enter overlay mode.
Created attachment 203282 [details] [review] main: Use the overlay-key setting Previously, we hardcoded Super_L and Super_R to hide the overview when in the overview.
*** Bug 634242 has been marked as a duplicate of this bug. ***
Review of attachment 203282 [details] [review]: You need to expose MetaDisplay->ignored_modifier_mask and mask with that or this won't work if caps-lock/num-lock are on. Maybe consider whether it makes sense to just add a key binding actin for this that you can return out of get_keybinding_action(), even if it's "special"/
I have the same problem. 1. the "windows" key is _effectively_ hardcoded from user's point of view as re-defining it requires arcane knowledge of where the settings are and how to change them using a gconf tool. 2. the default setting is _annoying_ at best. Shortcuts which use "windows" key are broken because of it. For example, assign <windows>+W as a shortcut for closing a window (to closely match Mac OS X shortcuts). Try using it to close a window. The window disappears _and_ the user is switched to "activities" mode. So the normal behavior is broken, and that is done in a counter-intuitive way. 3. in settings for keyboard shortcuts there is an item called "Show the activities overview". By default it is not set (another counter-intuitive thing). Setting it to something makes that shortcut work as an _additional_ shortcut for showing the "activities". And best of all, pressing it again returns user to the normal mode. 4. changing the hidden shortcut by modifying the mutter's gconf entry breaks things. Pressing that shortcut brings up the "activities" but pressing it again does not do anything. --- I guess I see what is the root of all this nightmare. You cannot set "Windows" key alone as a shortcut in the "keyboard shortcuts". It is not allowed to have shortcuts made of a single modifier key. So you cannot use "windows" key as a shortcut for "activities" using normal means. And someone must have decided that instead of fixing the original deficiency it is OK to do it in a hacky way by intercepting the "windows" key in mutter. Nice. The same problem is in Unity. And then how can you be surprised people do want to have Gnome 2 on their desktops instead of other, supposedly more convenient alternatives? :-) Frankly, I would have been surprised Gnome 3 is not considered to be an "alpha". Because such massive deficiencies just have no right to be in a released software.
(In reply to comment #5) > 2. the default setting is _annoying_ at best. Shortcuts which use "windows" key > are broken because of it. For example, assign <windows>+W as a shortcut for > closing a window (to closely match Mac OS X shortcuts). Try using it to close a > window. The window disappears _and_ the user is switched to "activities" mode. > So the normal behavior is broken, and that is done in a counter-intuitive way. Is this a shortcut you set in the System Settings panel? This should be fixed in GNOME 3.4. > 3. in settings for keyboard shortcuts there is an item called "Show the > activities overview". By default it is not set (another counter-intuitive > thing). Setting it to something makes that shortcut work as an _additional_ > shortcut for showing the "activities". And best of all, pressing it again > returns user to the normal mode. > > 4. changing the hidden shortcut by modifying the mutter's gconf entry breaks > things. Pressing that shortcut brings up the "activities" but pressing it again > does not do anything. That's what this bug is about. > --- > > I guess I see what is the root of all this nightmare. You cannot set "Windows" > key alone as a shortcut in the "keyboard shortcuts". It is not allowed to have > shortcuts made of a single modifier key. So you cannot use "windows" key as a > shortcut for "activities" using normal means. And someone must have decided > that instead of fixing the original deficiency it is OK to do it in a hacky way > by intercepting the "windows" key in mutter. Nice. The "hacky way" is pretty much the only way to handle this case, because that's how X works. There's a few bugs in the handling, though, and we'll get around to fix them. I believe Florian had a patch for this somewhere. > Frankly, I would have been surprised Gnome 3 is not considered to be an > "alpha". Because such massive deficiencies just have no right to be in a > released software. Bugs exist. We'll fix them.
(In reply to comment #4) > Review of attachment 203282 [details] [review]: > > You need to expose MetaDisplay->ignored_modifier_mask and mask with that or > this won't work if caps-lock/num-lock are on. Maybe consider whether it makes > sense to just add a key binding actin for this that you can return out of > get_keybinding_action(), even if it's "special"/ Do you mean adding the ability to handle mods-only shortcuts to the keybinding handler? It could work...
I have a terrible idea that you're going to hate...
Created attachment 211633 [details] [review] display: Add a way to keep keybindings running during a modal Plugins may want to allow keybindings during a grab for various reasons. Yadda yadda this is going to be rejected why am I even writing a commit message.
Created attachment 211634 [details] [review] main: Add support for keeping keybindings running using a modal and all that fun stuff
I'm not suggesting these patches for inclusion as is, just the basic principle of running keybinding handlers in the overview.
> Is this a shortcut you set in the System Settings panel? This should be fixed > in GNOME 3.4. Yes. Thank you! This is really great news.
Still hardcoded in 3.4: /usr/share/gnome-shell/js/ui/main.js: // This isn't a Meta.KeyBindingAction yet if (symbol == Clutter.Super_L || symbol == Clutter.Super_R) { overview.hide(); return true; }
Created attachment 221248 [details] [review] keybindings: Add MetaKeybindingAction for overview-key Currently gnome-shell hardcodes <super> as overlay key when it has a keyboard grab. In order to fix this, add a corresponding keybinding action.
Created attachment 221249 [details] [review] main: Do not hard-code <super> as overlay-key Use the new OVERLAY_KEY keybinding action instead of special-casing the overlay-key to make sure the same key will be used in- and outside the overview.
Review of attachment 221249 [details] [review]: Sure.
Review of attachment 221248 [details] [review]: Is there a reason you can't check both the keycode and the mask as part of the normal keybinding process? Some one who sets the keybinding to "<Super>G" should be able to do things, I guess.
Comment on attachment 221248 [details] [review] keybindings: Add MetaKeybindingAction for overview-key Attachment 221248 [details] pushed as 6c39852 - keybindings: Add MetaKeybindingAction for overview-key (In reply to comment #17) > Is there a reason you can't check both the keycode and the mask as part of the > normal keybinding process? Some one who sets the keybinding to "<Super>G" > should be able to do things, I guess. That's not how overlay-key currently works, and I'm not sure it should. Making it accept both "raw" keys (like 'Super_L') and keybindings sounds like a lot of effort for very little benefit - keep in mind that we already have a "normal" keybinding action for triggering the overview (panel-main-menu), which is even exposed in control-center.
Comment on attachment 221249 [details] [review] main: Do not hard-code <super> as overlay-key Attachment 221249 [details] pushed as 028e831 - main: Do not hard-code <super> as overlay-key