GNOME Bugzilla – Bug 494210
Move "default" keybindings to be hard-coded
Last modified: 2011-11-16 18:41:04 UTC
For some (or a lot, depending on your view), it makes sense to allow both the default keybinding (which would come from X itself), as well as a user-specified value. eg. Lock screen wants Ctrl+Alt+L as a default for most machines, but XF86Lock should be bound as well, so that Fn+F2 works as expected on Thinkpads and other machines with such a button. So, I've moved all those actions to be hardcoded, so any user-setting is on top of those hard-coded values. I've also renamed the power to logout, to avoid confusion, and removed sleep, as GPM should be handling it (it's suspend).
Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=363251
Created attachment 98668 [details] [review] gnome-control-center-hardcode-keys.patch Untested, but compiles.
I'm not sure this is a good idea. First of all, starting to hardcode stuff now that we've outsourced the settings seems undesirable. What happens if I want to use one of the hardcoded keys for something else? Do I need to change my keymap? It also means that those shortcuts will no longer be shown in the capplet. Also, and this may even be the most important reason, it becomes impossible to unbind keysyms. I don't remember exactly why, but I've had to do this once because some not-very-well-integrated app insisted on using a certain keysym that g-s-d had a grab on. The right way to fix this would be to allow multiple keybindings for one action (bug #373934). This would obviously also have some impact on the UI, though.
(In reply to comment #3) > I'm not sure this is a good idea. > > First of all, starting to hardcode stuff now that we've outsourced the settings > seems undesirable. What happens if I want to use one of the hardcoded keys for > something else? Do I need to change my keymap? It also means that those > shortcuts will no longer be shown in the capplet. Also, and this may even be > the most important reason, it becomes impossible to unbind keysyms. Keysyms, as applied by the X server are only available to grab and use when they're in the keymap. With a default keymap setup (ie. one of the "inet" keymaps), keysyms will be associated to real keys. So the XF86Stop keysym will be associated with the Stop physical key. Wanting to be able to launch the web browser when pressing Stop sounds like too much flexibility to me. > I don't remember exactly why, but I've had to do this once because some > not-very-well-integrated app insisted on using a certain keysym that g-s-d had > a grab on. But was that a specific keysym (such as XF86Play) the application was trying to bind, or a key combination (Ctrl+Alt+S)? If the latter, the application is definitely broken, but wouldn't be impacted by the changes above. > The right way to fix this would be to allow multiple keybindings for one action > (bug #373934). This would obviously also have some impact on the UI, though. I hate the idea, but my comments are already in that bug.
FYI, I find the current behaviour confusing as I (like a lot of people) have two machines -- one desktop at work and a notebook at home. On the desktop machine with a ordinary keyboard (without multimedia keys) I configured keyboard shortcuts to mute (Shift + Alt + Left), increase volume (Shift + Alt + Up) and decrease volume (Shift + Alt + down) (I think those are the default keyboard shortcuts Gnome used for this in the old days, but I'm not really sure; doesn't matter much). My notebook has multimedia keys. But quite often I try to use the keyboard shortcut on my notebook as I'm used to them from my machine at work. I of course could configure my Gnome session to do what I want the machine to do when I hit the keyboard shortcuts -- but then the multimedia keys won't work anymore which is also not really ideal :-/ So I'd really like to see this fixed like the patch Bastien proposed afaics does. On the other hand I understand the points Jens raised. But well, Bastien's patch is a sane default: You can use the same keybinding on all machines and if one of them has multimedia keys they will work in as well. No conflicts, no confusion, most people happy. Most, as yes, some people (very few I suppose) might want to override this behavior. Giving them a chance to do so in the UI likely makes the UI to complicate to use. Maybe one or multiple gconf-keys that disables the "events from the multimedia keys are handled directly" behavior could do the trick that makes both of you happy?
We don't necessarily need a way to override them in the UI, but I do believe it is necessary to be able to tell that a certain key combo is already bound. I also think that a clean implementation would do this by allowing multiple bindings for one action, even if we don't expose it as such in the UI.
What can be done: - modify the control-center capplet to accept a GConf key that's a string or a list of strings. Only modify the first item of the list and hide the second one by default (might break concurrent accesses, as we read/update/write?) - make sure the capplet warns about the key already being used even for the second one. But what do we do tell the user to do to disable the key, as the "hard-coded" might not appear in the list? - Add support for multiple keys for one keybinding in g-s-d This patch is really needed to provide decent defaults, and for things like HID remote controls to work as expected.
Conceptually, I'd prefer option 3. I am, however, not quite sureof the UI. There's a mockup of that functionality somewhere in bugzilla, andI didn't particularly like the result. As a first cut and to mitigate that issue a bit, it might also be ok to add support for multiple keys backend-wise, but only expose the first in the UI.
(In reply to comment #8) > Conceptually, I'd prefer option 3. That's not different options, that's the steps of a solution. I don't really want to have multiple shortcuts show up in the UI either...
(In reply to comment #9) > That's not different options, that's the steps of a solution. Oh. In that case, I guess I surprisingly like the complete solution most. ;-)
Created attachment 113866 [details] [review] First patch This one changes the internals to support more than one key per GConf key. The second step would be to check whether we have a single key (string), or a list of keys (list).
The patch has some issues with tabs vs. spaces. - if (keys[i].key != NULL) { - grab_key (keys[i].key, FALSE, manager->priv->screens); + if (keys[i].key_list != NULL) { The if's redundant. +match_key_list (GList *key_list, XEvent *xev) +{ + GList *l; + + if (key_list == NULL) + return FALSE; This one, too. + if (keys[i].key_list == NULL) + continue; And this one. Otherwise looks good.
(In reply to comment #12) > The patch has some issues with tabs vs. spaces. I'll try to fix that up, but it looks like the original file uses spaces, which is utter crap. Might be my fault :) > - if (keys[i].key != NULL) { > - grab_key (keys[i].key, FALSE, > manager->priv->screens); > + if (keys[i].key_list != NULL) { > > The if's redundant. Fixed. > +match_key_list (GList *key_list, XEvent *xev) > +{ > + GList *l; > + > + if (key_list == NULL) > + return FALSE; > > This one, too. Removed. > + if (keys[i].key_list == NULL) > + continue; > > And this one. Removed.
Created attachment 114005 [details] [review] Broken patch Just so that I don't have to copy it around...
Mass move to new component "Keyboard" where the keyboard shortcuts live in GNOME 3.
The "Lock" (XF86ScreenSaver) key is already handled by media-keys, and hardcoded. The others need their own discussion.