GNOME Bugzilla – Bug 659899
<Super>+<key> erratic with "Custom Shortcuts"
Last modified: 2016-06-27 12:18:33 UTC
I Use custom shortcuts for keyboard layout, Super + U - English Super + I - Indian (devanagari) I added the shorcts in Custom Shortcuts with commands Name Command Shortcut Hindi setxkbmap -layout in,us Mod4+I English setxkbmap -layout us,in Mod4+U0939 (key U in devanagari keyboard layout) I'm on Archlinux, running Gnome 3.1.92, bug https://bugzilla.gnome.org/show_bug.cgi?id=624869 is stated resolved, but I'm still having the bug. $mutter --version mutter 3.1.92 Thanks.
That's because the Super key is used by gnome-shell already. See also bug 655615. Also, we only capture keys with the default keymap, and you changing the keymap from underneath gnome-settings-daemon can't do it any good. Try using a variant of that: gsettings set org.gnome.libgnomekbd.keyboard layouts "['gb', 'fr']" It might work...
Hi, the gsettings command did not 'release super key' from gnome shell in anyway; and "setxkbmap -layout gb,fr" works just fine in command line, doesn't it? Same thing, I assigned Mod4+U to the above "gsettings set org.gnome..." command and Mod4+I to another one. same bug, command is not executed with the assigned Super key shortcut, as expected. Kinda have to struggle with them to get them work. as a test, why don't you try to add Mod4+U with, say, a command like "notify-send Hello there" or "gedit" Just a thought, I think gnome-shell should "grab" the super key *on*release* event and not *on*being*pressed*; so that both the single and mod key behaviours could work. Thank you.
one more thing, Right there in the keyboard=>Custom Shortcuts; when I press Mod4+U (which I assigned); The super key is ignored and 'u' is being shown in the 'text filter'; I noticed: The patch in the fixed bug, seems to have only Fixed the Shortcuts->"Windows"->items but not other parts of Shortcuts like Custom shortcuts. The Mod4+U key works just fine with items in "Windows" Shortcuts like "Activate the window menu" or "Move window"; hence, I presume that the patch in bug 624869, only patches the "Windows" shortcuts not other items. thanks.
If the keys being pressed don't do anything, then it's a gnome-shell bug.
*** Bug 661827 has been marked as a duplicate of this bug. ***
I have similar problem binding Super->n for next track. Often that happen, is the first time I do it while keeping the super key press doesn't work, but if I press N again, it work every time. So, Super->N doesn't work, keeping Super still press, I press N again, and it working, if by still keeping the super key press and I press N over and over again, it work every time.
Seeing the same. Binding Super+T to the "Start Terminal" command works as expected. Binding Super+T to a custom command launching gnome-terminal (or anything else) is accepted, but pressing it has no effect. Any combination I've tried with Super has the same problem.
I believe this bug talks about the same thing: https://bugzilla.gnome.org/show_bug.cgi?id=662580 I won't mark it as a duplicate for now letting developers to decide. But this is a very annoying thing. Basically the whole purpose of "win" existence is to be used for custom shortcuts. "Alt" is taken by menus (Alt+F for "File", etc), and Ctrl is often used up by the program you're working with at the moment, leaving "Win" to be the only available option for custom, system-wide hotkeys.
Eugueny, having read both bugs, I agree that bug #662580 and this one appear to be duplicates.
*** Bug 671827 has been marked as a duplicate of this bug. ***
By the way, configuring it through gnome-control-center, <Super>x won't work at all, just omiting "Win". But changing <Surer>x to <Mod4>x brings an effect as like Marc described above, i. e. you should, holding "Win", press x two times, to get it work; pressing <Mod4>xxx makes it work two times. After that gui shows Mod4+Super+Hyper+X.
I can confirm the behavior, exactly as Nikita Malyavin stated. I would also add, after changing <Super> to <Mod4> with dconf-editor the Gtk, and attempting to perform the shortcut, the Gtk filter bubble appears. I.e. creating a shortcut to launch /usr/bin/foo with <Mod4>x, then doing [win] + [x] while nautilus is in the foreground will create a filter bubble containing "x", just as if the [win] key was not being pressed at all.
This is a regression from 3.2, confirming. Probably is the same as #662580.
This bug was first reported in 3.1, so it can't be a regression from 3.2.
*** Bug 674656 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > This is a regression from 3.2, confirming. Probably is the same as #662580. Good point, the regression was that I didn't use custom shortcuts before as we had a built-in one to launch a terminal..
Re this not being a regression from 3.2. There does appear to be some change from 3.2 to 3.4. I originally set up all my Mod4+X shortcuts in 3.2, and they worked fine (along with using the left window key for the shell's overview). When I moved to 3.4, they all appeared as Mod4+Super+Hyper+X in the shortcut settings window (as described above) so I re-bound them, thinking this was wrong. I then saw the behaviour reported here. Unfotunately I recall if they worked before re-binding. I have a work-around that suits me. By editing the bindings using gconf-editor to use "Mod4" rather then "Super" (as described above) and by using the "make caps lock an additional super" setting in keyboard options, they work again as before. The window key no longer brings up the overview, but caps lock does, and it closes it too -- someting that does not happen if you re-assign the overlay key using dconf or gsettings (org.gnome.mutter overlay-key). Maybe this work-around will suit others too.
All of these work-around solutions fail to address one simple and probably fixable flaw: Gnome Shell should listen for a [Win] key press and release, but should *never* capture it. Just let the key press continue to bubble. In fact, I'm willing to look at fixing it myself if someone will point me to the right source file/function.
(In reply to comment #18) > All of these work-around solutions fail to address one simple and probably > fixable flaw: Gnome Shell should listen for a [Win] key press and release, but > should *never* capture it. Just let the key press continue to bubble. > > In fact, I'm willing to look at fixing it myself if someone will point me to > the right source file/function. If it was easy to listen for a key press without capturing it away from other processes, we would have done it that way. It's basically impossible with the X keyboard model. The only solution I know of for this bug is to have a single process (probably mutter) handle all global key shortcuts and send signals over D-Bus.
There must be more to it than this. If gnome-shell has to do what it does now (in 3.4) why did all my shortcuts work in 3.2? Is it not possible to go back to whatever it was that 3.2 did?
(In reply to comment #20) > There must be more to it than this. If gnome-shell has to do what it does now > (in 3.4) why did all my shortcuts work in 3.2? This issue has already existed in 3.2, so my guess is that "your shortcuts" happened to be provided by the wm (where <super> works fine) and were moved to gnome-settings-daemon when moving to GSettings (e.g. the screenshot shortcuts) or removed in favor of custom shortcuts ("Launch Terminal").
Does this mean I'll never be able to map <Super>R to launch the terminal again?
(In reply to comment #22) > Does this mean I'll never be able to map <Super>R to launch the terminal again? Basically yes, though in this case you could create a workaround using a gnome-shell extension (using global.display.add_keybinding())
Any chance we could just move the keybindings bits of gsd into gnome-shell ?
(In reply to comment #23) > (In reply to comment #22) > > Does this mean I'll never be able to map <Super>R to launch the terminal again? > > Basically yes, though in this case you could create a workaround using a > gnome-shell extension (using global.display.add_keybinding()) Interesting ... this leads to wonder why an gnome-shell-extension can do it when gnome-settings-daemon can't ? What's the difference ?
Sorry, I don't think Florian actually meant "never again". He meant "until this bug is fixed", just to clear things up. (In reply to comment #25) > Interesting ... this leads to wonder why an gnome-shell-extension can do it > when gnome-settings-daemon can't ? What's the difference ? A shell extension is in the same process as mutter, and has the same power as mutter.
(In reply to comment #26) > A shell extension is in the same process as mutter, and has the same power as > mutter. Thats explains why it's a "global.display" call. Thanks. It should be possible to make an extension that reads custom shortcuts in gsettings and call global.display.add_keybinding on them ! Will give a try.
I tried making a shell extension that would just load the existing keybindings, but in gnome-shell 3.4, it can't be done because: 1. all custom keybindings have the same key name "binding", so only the first one is used. 2. mutter_display_add_keybinding() expects the keybinding to be a Strv, but in the gsd.media-keys schema it's a string. I can't use my own key because 1. mutter_display_add_keybinding() command takes a GSettings object as input, but extensions can't install GSettings schemas 2. I though of just making my own memory backend that would duplicate the real one, but g_memory_settings_backend_new() is not introspected. So anyway, shouldn't we just move the media-keys applet from gsd into gnome-shell ? Shouldn't just move all of gsd into gnome-shell while we're at it ?
My mistake, I didn't notice that extensions can install schemas now, but that doesn't help me so much if I want more than one custom keybinding.
(In reply to comment #29) > [...] but that doesn't help me so much if I want more than one custom > keybinding. Custom keybindings are of course not limited to one. org.gnome.settings-daemon.plugins.media-keys.custom-keybinding is a relocatable schema, e.g. it is shared by all custom keybindings, with each binding using a different path. The list of paths in use is stored in GSettings as well, you can inspect it with gsettings get org.gnome.settings-daemon.plugins.media-keys custom-keybindings The result is a list of strings in the form of "/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/", which you can then use to get the actual keybindings: gsettings list-recursively org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/ You are right though that the schemas used by g-s-d and mutter are different, so I doubt that you can come up with an extension which re-uses the g-s-d keybindings directly.
The problem with having the same name is that mutter_display_add_keybinding() that's they GSetting's key name as the key for it's internal hashlist. That said, with a bit of hackery, I wrote an extension having it's own schema and using a temporary GSettings in delay mode (that is never written to disk), but that is kept synchronized with GSD, I managed to write an extension that mirrors the gsd key bindings into gnome-shell, it's on e.g.o as extension 300!
Olivier, is your code available anywhere else? As far as I can see the extensions jump from 298 and 299 straight to 302...
Here it is: http://people.freedesktop.org/~tester/custom-keybindings@ocrete.ca.zip Let's hope the extensions.g.o approval can come soon.
Thanks very much for the speedy response Olivier! I tried testing it out, but the schemas directory appears to be empty. I figured that this might be something to do with it dynamically copying over the gnome-settings-daemon data, but reading through the code and trying it without a gschemas directory at all also didn't seem to work. The first error was about a missing gschemas.compiled, and the second suggested checking my installation. Was there a file missing from the zip you linked to, or have I botched the installation in some way?
(In reply to comment #34) > I tried testing it out, but the schemas directory > appears to be empty. This is very off-topic for bugzilla (which is not a support forum), but note that if you happen to use Ubuntu, the extension will not work, as they patched gnome-settings-daemon/gnome-control-center to use GConf for keybindings.
I think the schemas weren't in the zip file, I added them and updated it (again sorry for abusing bugzilla for this).
On the topic of fixing the actual bug, what is the preferred approach here? To ask the X people to add somethign to fix grabs? or to just move media-key handling to gnome-shell ?
(In reply to comment #19) > If it was easy to listen for a key press without capturing it away from other > processes, we would have done it that way. It's basically impossible with the X > keyboard model. The only solution I know of for this bug is to have a single > process (probably mutter) handle all global key shortcuts and send signals > over D-Bus. Could we have g-s-d grab the overlay key, and send a special signal which we listen to?
(In reply to comment #38) > Could we have g-s-d grab the overlay key, and send a special signal which we > listen to? That would mean that <super> can no longer be used in wm keybindings ...
May I suggest making an option to disable the windows-key-shows-overlay behavior, so i can bind it to Super+something_else? I would guess some people are used to this feature by now, so it should probably be off by default, but that would make it possible for people to change the behavior. I also noticed that key assignments still appears as "Super", even when "Hyper is mapped to Win-keys" is set in the layout. If Hyper is a separate modifier, a solution could be to let the windows key show as Hyper when that is selected in the layout, so that shortcuts could be set with Hyper instead.... if that is really a separate modifier. I am not familiar with the code here, so this might not make sense from a developer perspective though.
(In reply to comment #40) > May I suggest making an option to disable the windows-key-shows-overlay > behavior, so i can bind it to Super+something_else? gsettings set org.gnome.mutter overlay-key '""'
*** Bug 679806 has been marked as a duplicate of this bug. ***
had this same problem after upgrading. The dconf path is org/gnome/settings-daemon/plugins/media-keys. The predefined shortcuts live there. Custom shortcuts live further down under custom-keybindings/custom0 (or custom1, and so on). Changing <Super> to <Mod4> in my shortcuts fixed the problem. http://superuser.com/questions/415675/gnome-shell-3-4-and-a-super-key-related-shortcut
I'm surprised to see that toggle nautilus and toggle terminal extensions are working just fine and as expected with super+e and super+t shortcuts! https://extensions.gnome.org/extension/538/toggle-nautilus/ https://extensions.gnome.org/extension/477/toggle-terminal/ whereas setting super+e, super+r or super+t keys with control center keyboard shortcuts simply won't work the way we expect! Could you please look into toggle nautilus and toggle terminal extensions, how they are doing it differently?
They're grabbed in the Shell process rather than in gnome-settings-daemon. This discrepancy will be fixed for 3.8.
gnome-settings-daemon refers keygrabbing to gnome-shell nowadays, so let's consider this fixed.
Hi Florian, do you mean it's fixed in 3.8? I'm on Fedora 18 with Gnome 3.6 and still see this problem, so I'd just like to understand, thanks.
(In reply to comment #48) > Hi Florian, do you mean it's fixed in 3.8? Yes, sorry I didn't make this clearer. You should be able to use <super> in custom shortcuts once you upgrade to Fedora 19.