GNOME Bugzilla – Bug 645200
Alt+Tab, Alt+Above_Tab, Ctrl+Alt+Tab hardcode Alt modifier
Last modified: 2011-09-20 19:08:21 UTC
I built GNOME Shell from jhbuild today and found that Ctrl+Alt+Tab switched between the various Shell places with keyboard navigability (very useful). I quickly found this keyboard shortcut to be very uncomfortable for my hand to do frequently. I decided to switch it to the much more logical (and comfortable) Meta/Super/Win+Tab, but as soon as I did the behavior of the shortcut got very strange; think of it like a "turbo button" on a video game controller where while you're holding down the button, it acts like you're pressing it a dozen times per second. For Shell to be usable only using the keyboard (or mostly), it needs to have comfortable keyboard shortcuts that don't strain my left hand.
In general <Super> shortcuts don't work too well due to interaction with the overview key handling - should be fixable if someone puts some time into it. Going to mark this as a duplicate of the existing Mutter bug on the subject, though there might be some issues specific to Control-Alt-Tab. In terms of comfort - we don't really see control-alt-tab as a primary way of navigating via the keyboard. Generally, we would expect most primary interaction to be done by search. *** This bug has been marked as a duplicate of bug 603778 ***
(In reply to comment #1) > Going to mark this as a duplicate of the existing Mutter bug on the subject, > though there might be some issues specific to Control-Alt-Tab. Yeah, there are; altTab.js and ctrlAltTab.js explicitly exit when you release Alt. I think this could be fixed by making shell_wm_key_handler() include binding->mask in the signal parameters, and then updating the js code to use that.
*** Bug 648028 has been marked as a duplicate of this bug. ***
*** Bug 649236 has been marked as a duplicate of this bug. ***
Created attachment 195838 [details] [review] alt-tab: Do not hardcode ALT modifier While we allow for arbitrary modifiers in keybindings, both the alt-tab and ctrl-alt-tab popups close when ALT is not present in the modifier mask, resulting in ALT being de-facto hardcoded. Instead, pass the actual modifier mask when invoking the popups. (In reply to comment #2) > I think this could be fixed by making shell_wm_key_handler() include > binding->mask in the signal parameters, and then updating the js code to use > that. Yup, let's do it then!
Comment on attachment 195838 [details] [review] alt-tab: Do not hardcode ALT modifier This introduces a slight change, which is that now if you start out with Alt+Shift+Tab (or Super+Shift or whatever), then it will stay in the switcher as long as *either* Alt or Shift is held down, rather than always exiting when Alt is released. (Likewise, for Ctrl+Alt+Tab, now you need to release both modifiers.) mutter's default behavior is to exit when the modifier with the highest-valued mask bit is released
Created attachment 195925 [details] [review] alt-tab: Do not hardcode ALT modifier (In reply to comment #6) > mutter's default behavior is to exit when the modifier with the highest-valued > mask bit is released Sure.
Created attachment 196971 [details] [review] alt-tab: Do not hardcode ALT modifier Rebased to master.
Created attachment 197009 [details] [review] alt-tab: Do not hardcode ALT modifier While we allow for arbitrary modifiers in keybindings, both the alt-tab and ctrl-alt-tab popups close when ALT is not present in the modifier mask, resulting in ALT being de-facto hardcoded. Instead, pass the actual modifier mask when invoking the popups. -- Hey Florian, this looks good, I think we should land it before the freeze. I edited your patch a bit to factor out the primaryModifier() function, hope you don't mind.
Comment on attachment 197009 [details] [review] alt-tab: Do not hardcode ALT modifier looks right
Attachment 197009 [details] pushed as 566d566 - alt-tab: Do not hardcode ALT modifier