GNOME Bugzilla – Bug 559816
Doesn't update keybindings being disabled/cleared
Last modified: 2017-07-21 10:43:49 UTC
Please describe the problem: The handling of keybindings is incoherent between "keyboard" and "keybindings". Actually, I think that the keybinding system should be restructured to accept different keybindings than it actually does, and the keyboard disposition commutation should just be one of the options in the keybindings window. Then, obviously, the keyboard window could as well implement the setting of keybindings of its particular actions, but just borrowing some code (or at least the organization) than the keybindings manager. Ok, please forgive me if I talk of things I really don't know: maybe there is a subtle better fix (and maybe the bug is in the keybindings properties, not in keyboard settings), but I have the impression my idea of system change would be better. Steps to reproduce: I hope I'm translating back in English all the strings I see in Italian: 1. Open the keyboard manager, "dispositions" tab 2. Click "other options" 3. Under "disposition commutation" (last of the list), check "Right Ctrl key changes disposition" (notice "The Ctrl keys together change disposition" doesn't work at all for me, but this would be a different bug) 4. now open keybindings properties, pick the action you desire and click on the right to set its keybinding: i.e: Ctrl+o. But... oops, you forgot that right Ctrl does something other, and so you pressed THAT Ctrl, and instead of "Ctrl+o", you just see ISO_NEXT_GROUP. Never mind, you deactivate that action... but the right Ctrl still executes it! And if you deactivate the choice of right Ctrl to change keyboard under the keyboard settings, right Ctrl still executes the action set in keybindings properties! Actual results: In this moment, under keybinding properties, I have no keybinding selected for "switch to workspace 3". However, both right Ctrl and the combination "Left Ctrl + V" (a combination I gave to it while trying to overwrite the former) execute this action! Expected results: I would expect that keyboard settings' keybindings and normal keybindings are intercepted at the same level, instead of keybindings manager receiving a key apparently already modified by the keyboard settings' particular keybindings handler and not being able to handle it. Does this happen every time? Yes (I also tried in a guest session, from scratch). Other information: If some testing is needed, I can do it. If my idea of unifing interception of keybindings makes sense, the only basic change to keybindings settings would be that it should be able to also intercept: - a single Ctrl (if you press a combination, you take it as a modifier, if instead it is just pressed and released, you take it as a key) - the two ctrls - the two Alts and so on... (just what is accepted at the moment by the keyboard manager) There is no need instead to change the keyboard settings interface (although I think it could be better), there is only need to make it use the same backend as other keybindings.
After rebooting, the wrong assignment(s) of keys has disappeared (notice the bug itself is still valid).
First of all, both settings (keyboard and keyboard shortcuts) are normally handled by the same component (gnome-settings-daemon). That's not the problem here, though. (In reply to comment #0) > I hope I'm translating back in English all the strings I see in Italian: Unfortunately, no. > 3. Under "disposition commutation" (last of the list), check "Right Ctrl key > changes disposition" The list of options you get there depends on your version of xkeyboard-config and the X server, and the ordering depends on the names, so that's not reliable. I suppose you mean "Compose key position" -> "Right Ctrl is Compose"? At least I can reproduce the problem with that setting. The window shortcuts are handled by metacity, and for some reason metacity fails to update the shortcut even though it is cleared in GConf, and keeps using it. Moving to metacity.
Thank you for fixing my imprecisions, i don't know what xkeyboard-config is. I found that the right string for "Right Ctrl key changes disposition" was instead "Right Ctrl key changes group.", but anyway, the bug is the same you noticed with "Right Ctrl is Compose" and has to do with use of Right Ctrl, not with the action I still think two different layers of keybindings interceptions are bad (the settings damon is evidently the same, but it is evident that _first_ the Right Ctrl is intercepted, _then_ the normal keybindings), but I also think you're far more expert than me, so I end my potential flame...
(In reply to comment #2) > The window shortcuts are handled by metacity, and for some reason metacity > fails to update the shortcut even though it is cleared in GConf, and keeps > using it. Can you tell me which GConf key we're talking about here?
I used /apps/metacity/window_keybindings/lower but I don't think it matters. Any leybinding should do.
So the problem is that when you enter a keybinding and then clear it, Metacity continues to honour the defunct keybinding?
Ahem, yes, I verified _this_ is the problem, and it has no particular correlation with keyboard settings' keybindings. Notice that if instead of being cleared, the keybinding is overridden with another one, the old one seems to be forgot. (it is not always true, since, as I reported, in a certain moment I had "Right Ctrl" and a standard keybinding pointing to the same action, for which no keybinding was no more assigned; but I'm not able at the moment to reproduce this particular behaviour)
*** Bug 587290 has been marked as a duplicate of this bug. ***
Still present in 2.27. I tested some more, and noticed that if you simply 1) assign a keybinding 2) delete it 3) assign a new keybinding the new one is _never_ considered, the old one stays.
I tried and reproduce these 3 steps by doing this : 1) Assign Ctrl+Shift+W to the "run terminal" action 2) Delete this keybinding 3) Assign Ctrl+Shift+X to the "run terminal" action Ctrl+Shift+X will launch a terminal, while Ctrl+Shift+W will do absolutely nothing. I'm running karmic and gnome-control-center 2.27. I took a look at gconf while doing this, and the behaviour of /apps/metacity/global_keybindings/run_command_terminal may explain this bug : - after 1), the value of run_command_terminal is "<Shift><Control>w"; - after 2), the value of run_command_terminal is "" (left blank); - pressing Ctrl+Shift+W will open a new terminal; - setting the value of run_command_terminal to "disabled", manually in gconf will prevent Ctrl+Shift+W from doing anything.
Created attachment 140819 [details] [review] Patch that allows keybindings to be unset. As I was thinking, when deleting a keybinding, gnome-keybindings-properties writes "" in gconf, instead of "disabled". So I guess this simple patch should fix the bug.
No, this should be fixed in metacity. Setting a keybinding to "" is valid if not better than "disabled".
Sort of a trainwreck. gsd-keybindings-manager.c supports "" or "Disabled". metacity supports only "disabled". gnome-keybinding-properties.c supports "" or "disabled" when reading and writes "". I'm not sure how changing what gsd-keybindings-properties.c writes from "disabled" to "" (http://git.gnome.org/cgit/gnome-control-center/commit/?id=4a8637592) could conceivably be considered compatible. It was straight-up breakage. It doesn't matter if "" was better than "disabled" - "disabled" was what GNOME was using. I'm going to propose a patches for Metacity and Mutter to accept either "" or "disabled" because that's the only thing that's going to get people's existing keybindings working properly, but blech!
*** Bug 613236 has been marked as a duplicate of this bug. ***