GNOME Bugzilla – Bug 649389
Cannot set keyboard shortcuts that use the Windows (Mod4) key
Last modified: 2013-04-09 12:40:33 UTC
To reproduce: 1. Under Keyboard Setting > Shortcuts > Launchers, it is possible to set Launch Terminal using a Windows key shortcut (e.g., Mod4+T), and it works. 2. None of the other items in Keyboard Setting > Shortcuts > Launcher work if set using a Windows (Mod4) keyboard shortcut. 3. No customs shortcuts created in Setting > Shortcuts >Custom Shortcuts will function if set using the Windows (Mod4) key. For example, firefox (Mod4+F) or banshee (Mod4+M) will not work. 4. Custom shortcut will work, however, using different key combinations such as firefox (Ctrl+Alt+F).
I am using gnome-control-center 3.0.1.1-1 under Arch Linux.
I noticed that Windows key shortcuts other than Mod4+T work somehow as follows: Press the Windows key (Mod4) two times in a row and hold it the second time, then also press the other key(s) of the configured shortcut e.g. Space for Mod4+Space (that I am used to summon Gnome Do with). You will see Gnome Shell entering its activity overview feature, when _releasing_ Mod4 the first time and leaving it when pressing and holding Mod4 the second time. Seems blocking of most Windows key shortcuts is related to the Gnome Shell feature being assigned to the Windows key release most of the time, except for the moment you leave the activity feature when pressing down the Windows key again.
Thanks for your response. I tried your suggestion of pressing the Windows key twice, holding it, and then attempting a custom shortcut. This time, it worked. It seems strange, though, that is possible to set a shortcut for launch terminal that can launch only pressing the Windows key once, whereas all custom shortcuts require pressing the Windows key twice. On a final note, should I mark this as resolved? Is the Windows key intended by design to require pressing it twice and holding it to launch a custom shortcut?
Mod4/Windows key is the button used by gnome-shell by default for the overview. You also don't seem to have mentioned any of the changes that you might have made in the layouts options (eg. did you enable "Meta is mapped to Win key" in the Alt/Win behaviour section? if not, this is never going to work properly anyway).
I was using "defaults" for the Alt/Win behavior when I filed the bug report. Following your post, I tried experimenting with "Meta is mapped to Win key", and all of the custom shortcuts launched normally (without having to double-tap and hold the Windows key). So what I gather is that if you use the "defaults" for the Alt/Win key, it is necessary to use the double tap and hold to get a Windows Key custom shortcut to work?
@Bastien I mapped Mod4 / Win > Meta and now gnome-shell doesn't show the overview anymore.
@Jacke I should have been a little bit more specific and should have noted that while choosing "Meta is mapped to Win Key" makes it possible to do one-touch Mod4 + 2nd key custom shortcuts, it disables ovelay behavior for Gnome-Shell. So I got the same result as you describe above when I mapped Meta to the Win Key.
Well, it's either/or. This bit of code is behaving exactly as GNOME 2.x was, the only difference being that gnome-shell would like to keep a hold of the Windows key.
I use the option "Alt ist der rechten Win-Taste zugeordnet und Super der Menü-Taste", which reverse-translates to "Alt is mapped to the right Win key and Super to the Menu key". Sorry, I cannot change the ui language to English for some reason. I use this option, because my notebook has no right Win key and this option allows to use the existing Menu Key, which I do not use, as a second Win key somehow. Playing around with this I noticed that gnome-shell only interferes with the real left Win key and not with the simulated one being mapped to the physical Menu key. So I now at least have a way to use my old keyboard shortcuts from the menu key. I think it should be possible to change or disable the keyboard shortcut for the overview feature of gnome-shell from within the normal keyboard shortcuts menu.
The explanation about gnome-shell needing to claim the Windows key seems bit off, for three reasons: 1. Launching a terminal still works when the Win key isn't remapped. Move workspace up/down do as well 2. Entering Win+<letter> into the shortcuts box still comes up with Mod4 regardless of the keyboard remapping. 3. Remapping Win to Hyper does the same thing as remapping it to mMeta even without rebinding all the shortcuts. ISTM that gnome-shell is just buggy. It's rather user-unfriendly to allow the user to enter shortcuts that then don't work. (While you're at it, wouldn't it make more sense to call it the Vendor key or something instead of Mod4?)
This looks like a duplicate of #624869 .
*** This bug has been marked as a duplicate of bug 642869 ***
*** This bug has been marked as a duplicate of bug 624869 ***
I have gnome-shell 3.2.2.1 and gnome-control-center 3.2.2 and still have exactly this issue. It seems to me that bug 624869 is a similar bug but no exactly the same one.
I can also reproduce this with gnome-shell 3.2.2.1 and gnome-control-center 3.2.2. Shortcuts like Win-L, Win-Space etc require pressing either Win-L-L or Win-Win-L.
still there in 3.4 (Arch Linux)~~ and btw, none of mod4 shortcut works for me.
Ok, the bug still exists in 3.6! I found that Win-<key>-<key> works and it doesn't really matter what the first <key> is just as long as it's not one of the working combinations (and it has to be released before the second <key>)! example: Win-Alt-R will work for custom Win-R combination (if you release Alt before the R) and this works with every other key (Shift,Caps Lock,Tab,Space,A,B,C,...)
It works fine in GNOME 3.8, which is the current version. There's absolutely no point in commenting on duplicated and closed bugs like this one.