Feature request: see origin of conflicting shortcuts

[lbenard]

There are some shortcuts that cannot be registered due to conflicts with Gnome (or maybe other applications), such as <Super>l that would lock the screen by default. However there are some bindings that do not seem to be used by Gnome such as <Super>p that raise the Unable to grab accelerator: <Super>p error when reloading the extension. I tried looking through all Gnome shortcuts & ran gsettings list-recursively org.gnome.desktop.wm.keybindings | grep "<Super>P" but I cannot find it anywhere.

Is there any way for an extension to get more details about the origin of shortcuts and give more detailed error messages?

thanks for you work on the extension, this became a must-have for me!

[e3rd]

Thanks! :))
Unfortunately, I don't have a clue how to get such list. I've been really glad few years ago that I succeeded implementing the error message "Unable to grab acc" so that the user knows which shortcut does not work. The reserved shortcut might even vary from Ubuntu version to version. I'd be glad if you advice what info should I add to the error message.

[lbenard]

I think every shortcut is supposed to be defined somewhere in a dconf entry. I searched a bit more and found those:

gsettings list-recursively org.gnome.shell.keybindings
gsettings list-recursively org.gnome.settings-daemon.plugins.media-keys
gsettings list-recursively org.gnome.desktop.wm.keybindings
gsettings list-recursively org.gnome.mutter.keybindings
gsettings list-recursively org.gnome.mutter.wayland.keybindings

My issue was in the org.gnome.mutter.keybindings schema where there was a org.gnome.mutter.keybindings switch-monitor ['<Super>p', 'XF86Display'] entry. Maybe it should be possible to read through those various dconf entries when there is an error to find what action it is associated to?

[e3rd]

You're right, this is proof of concept:

$ gsettings list-recursively org.gnome.shell.keybindings
org.gnome.shell.keybindings focus-active-notification ['<Super>n']

In test.gjs:

const Gio = imports.gi.Gio
let schema = 'org.gnome.shell.keybindings'
let settings = new Gio.Settings({ schema: schema })
let keys = settings.list_keys()
keys.forEach(key =>     
    log(`${key} => ${settings.get_value(key).deep_unpack()}`)
)

$ gjs test.gjs 
Gjs-Message: 15:15:41.846: JS LOG: switch-to-application-1 => 
Gjs-Message: 15:15:41.846: JS LOG: open-new-window-application-7 => 
Gjs-Message: 15:15:41.846: JS LOG: switch-to-application-7 => 
Gjs-Message: 15:15:41.846: JS LOG: screenshot-window => <Alt>Print
Gjs-Message: 15:15:41.847: JS LOG: toggle-message-tray => <Super>v
Gjs-Message: 15:15:41.847: JS LOG: switch-to-application-4 => 
Gjs-Message: 15:15:41.847: JS LOG: focus-active-notification => <Super>n
Gjs-Message: 15:15:41.847: JS LOG: open-new-window-application-2 => 
Gjs-Message: 15:15:41.847: JS LOG: switch-to-application-2 => 
Gjs-Message: 15:15:41.847: JS LOG: open-new-window-application-5 => 
Gjs-Message: 15:15:41.847: JS LOG: screenshot => <Shift>Print
Gjs-Message: 15:15:41.847: JS LOG: open-new-window-application-8 => 
Gjs-Message: 15:15:41.847: JS LOG: show-screen-recording-ui => <Ctrl><Shift><Alt>R

However, as <Ctrl><Shift><Alt>R is the same as <Ctrl><Alt><Shift>R it might be tricky and error prone to implement automatic key board lookup. Instead, I'd put this into README.

Would you mind doing a PR: a section in README with your findings + edit the error log at accelerator.js this.app.display(Unable to grab accelerator: ${this.shortcut})?

[lbenard]

Would you mind doing a PR: a section in README with your findings + edit the error log at accelerator.js this.app.display(Unable to grab accelerator: ${this.shortcut})?

I'm gonna try to find some time during the week but I might be able to do that!

[guy-borderless]

I'd note that now that you can invoke run-or-raise via the CLI, you can configure your shortcuts in the usual Settings → Keyboard → Custom Shortcuts and benefit from automatic binding collision detection.

1. Enable "listen to DBus" in the extension settings
2. Invoke via: gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell/Extensions/RunOrRaise --method org.gnome.Shell.Extensions.RunOrRaise.Call ",firefox,,*"

[guy-borderless]

@e3rd Come to think of it, shouldn't that become the preferred method? No need for a unique file anymore really methinks. Is a nicer CLI the blocker for this? I can pitch in.