After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649236 - Window switching doesn't work properly with modifier keys other than Alt
Window switching doesn't work properly with modifier keys other than Alt
Status: RESOLVED DUPLICATE of bug 645200
Product: gnome-shell
Classification: Core
Component: general
3.0.x
Other Linux
: Normal minor
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-05-02 22:44 UTC by Steven! Ragnarök
Modified: 2011-05-04 00:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steven! Ragnarök 2011-05-02 22:44:35 UTC
When changing the `Switch Applications' or `Switch Windows of an Application' shortcuts to use any modifier key other than Alt (such as Mod4 or Ctrl) the shortcut no longer displays the Task switcher overlay and instead will only toggle between two windows.

What should happen: Using any shortcut binding, the Application Switcher should behave as expected.

Steps to reproduce:
1. Change your keybinding for `Switch Applications' or `Switch Windows of an Application' to use any keybinding not including Alt.
2. Attempt to switch applications or windows using that keybinding.
Comment 1 Rui Matos 2011-05-02 23:43:31 UTC
So, in AltTabPopup.show() we have this code:

        // There's a race condition; if the user released Alt before
        // we got the grab, then we won't be notified. (See
        // https://bugzilla.gnome.org/show_bug.cgi?id=596695 for
        // details.) So we check now. (Have to do this after updating
        // selection.)
        let [x, y, mods] = global.get_pointer();
        if (!(mods & Gdk.ModifierType.MOD1_MASK)) {
            this._finish();
            return false;
        }

The race condition talked about in bug 596695 seems to be solved in metacity with code like this but more general, see keybindings.c:primary_modifier_still_pressed() et al.

We could 1) make primary_modifier_still_pressed() non-static and use it, 2) redo it's logic in JS or 3) punt on this.

IMHO we should just punt on this whole class of issues and just assume up-front that the only modifier we can sanely support is MOD1 and remove the setting. The rationale is that this creates a stronger mental model of gnome-shell's keybindings and sends a clear message to developers targeting Gnome that there are some keys they can't use on applications.
Comment 2 Dan Winship 2011-05-03 09:53:42 UTC

*** This bug has been marked as a duplicate of bug 645200 ***
Comment 3 Steven! Ragnarök 2011-05-04 00:28:53 UTC
Dan, thanks for the insight. I am using Gnome for the first time and, in fact, created my account here in order to file this bug. I prefer that the only desktop-wide modkey be Mod4 as it is the least overloaded modifier key at the application level. By restricting users and developers in something so arbitrary as which keybindings they can and cannot set. A precedent is set to stifle innovation before it starts. I suspect that there is a keybinding set more intuitive and efficient than the current one with Alt+Tab and that it would be unwise to assume that it will always and forever be the switch windows/applications keystroke.