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 677427 - media-keys keybindings should allow for multiple values
media-keys keybindings should allow for multiple values
Status: RESOLVED OBSOLETE
Product: gnome-settings-daemon
Classification: Core
Component: media-keys
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
3.10
: 762712 (view as bug list)
Depends on:
Blocks: 735691
 
 
Reported: 2012-06-05 03:23 UTC by Jeremy Bicha
Modified: 2019-03-20 11:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeremy Bicha 2012-06-05 03:23:26 UTC
When gnome-control-center switched to gsettings in 3.4, keyboard bindings became sets and it was possible to set multiple keyboard shortcuts to do the same action.

I would specifically like to set Ctrl+Alt+L and Super+L (like Windows) as keyboard shortcuts for org.gnome.settings-daemon.plugins.media-keys screensaver. (In fact, I think both of those shortcuts should be set by default for everyone, so feel free to do that when this bug gets fixed. Thanks!)

All of the keybindings in org.gnome.settings-daemon.plugins.media-keys should probably be switched to sets though, to be consistent.
Comment 1 Mikhail 2012-10-01 06:23:07 UTC
for me too....
ctrl-shift-l means left ctrl-shift, ctrl-shift-r means right ctrl-shift. But I want use both ctrl-shift for switch keyboard layout.
Comment 2 Bastien Nocera 2012-10-01 11:10:04 UTC
(In reply to comment #1)
> for me too....
> ctrl-shift-l means left ctrl-shift, ctrl-shift-r means right ctrl-shift. But I
> want use both ctrl-shift for switch keyboard layout.

We don't use this mechanism to capture and act upon modifier-only shortcuts to switch keyboard layouts. File a separate bug about this please.
Comment 3 Bastien Nocera 2016-02-26 13:21:03 UTC
*** Bug 762712 has been marked as a duplicate of this bug. ***
Comment 4 benpack101 2018-05-23 17:13:01 UTC
I agree I would like to see the value options for media-keys to be string arrays, like with shell keybindings(org.gnome.shell.keybindings) and not just strings as they currently are. 

My specific use case desire is the ability to have a keyboard shortcut to open the home folder without overriding the 'XF86Explorer' key.

If this is functionality that would be accepted, I would be happy to submit a patch myself.
Comment 5 Benjamin Berg 2018-06-05 14:24:34 UTC
I don't see a problem with adding support for this in gnome-settings-daemon. In particular because mutter already supports this in most cases.
We will need to make sure that migration works obviously.

It would probably make sense to bring this up on the control-center side and the designers though. There we currently only allow setting a single keybinding currently. This might be intentional, but could also have unpleasant side effects e.g. when the default has multiple bindings and setting it removes the alternatives.
Comment 6 Bastien Nocera 2018-06-05 16:14:02 UTC
There's probably an unfinished patch somewhere in bugzilla for this. The gist is that you'd use g_settings_get_value(), and check the type of the key, whether it's a list or a single string.

Note however that all the code in gsd-media-keys only knows how to handle a single shortcut per GSettings key. So you're going to have to modify that code to make sure that you minimise the work you're asking gnome-shell to do, and the keys you're going to ask it to capture, when the list is truncated, extended, reordered, or elements are modified.
Comment 7 GNOME Infrastructure Team 2019-03-20 11:00:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/184.