feature request: GlobalShortcuts portal

[jokeyrhyme]

Howdie, thanks so much for sharing your work here

I noticed that there has been work done on specifying a portal for GlobalShortcuts: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.GlobalShortcuts

This would be useful for communications apps that have push-to-talk functionality, as well as various other use cases

Do you know if this is likely to be on the roadmap? Or is it considered out-of-scope or otherwise not part of your project goals/vision?

Note that KDE does seem to advertise support for this portal: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/data/kde.portal#L3

To clarify: I'm grateful for the work shared here, and am curious about whether this work is already planned or if you'd accept a PR that implements this, I do not expect a timeline or ETA 🫂

[Drakulix]

This might not be part of the first alpha, but we have been waiting for this portal to arrive. We plan to make this a central part of our key-bindings and key-customization story, so support is definitely on the roadmap rather sooner than later.

It is not yet clear, how the key bindings would be communicated back to the compositor (likely through some non-existent private wayland protocol), but if you want to contribute a implementation of the frontend to the portal, that would be very welcome.

[jokeyrhyme]

Yeah, the trick is allowing xdg-desktop-portal-cosmic to communicate with cosmic-comp in order to set the keyboard shortcut

hyprland did implement a custom wayland protocol to allow xdg-desktop-portal-hyprland to talk to hyprland for this purpose: https://github.com/hyprwm/hyprland-protocols/blob/main/protocols/hyprland-global-shortcuts-v1.xml

cosmic-comp could also expose a DBus API, or have a separate UNIX socket, or we could adopt hyprland's wayland protocol, or come up with our own wayland protocol

Or (and I doubt this is the approach we'd take), xdg-desktop-portal-cosmic could directly modify cosmic-comp's config.ron, cosmic-comp could reload it after receiving an fs inotify or a SIGHUP or something

I did propose a general purpose solution that relies on DBus and shell scripts to make this work ( emersion/xdg-desktop-portal-wlr#240 (comment) ) but that wouldn't be necessary here seeing as xdg-desktop-portal-cosmic only has to support cosmic-comp (and vice versa)

[jokeyrhyme]

GlobalShortcuts portal briefly mentioned here: pop-os/cosmic-comp#283

[jokeyrhyme]

It is not yet clear, how the key bindings would be communicated back to the compositor (likely through some non-existent private wayland protocol)

Could/should cosmic-comp subscribe to changes in cosmic-config the same way other components do, and have that be the way it learns when keyboard shortcuts have changed?

[jokeyrhyme]

Ah, I'm just realising that keybindings set via GlobalShortcuts are likely session-only, and probably shouldn't be persisted to disk, so cosmic-config would need a separate session-only concept if it were to be used for communicating GlobalShortcuts with other components

[Drakulix]

Right so there are multiple open questions on this subject.

Lets first define some names:

• "Default Shortcuts" - Shortcuts cosmic-comp sets by default and possible dependent of other configuration. E.g. how some shortcuts already dependent on the workspace layout.
• "Static Shortcuts" - Shortcuts set by the user and expected to be persistent. Likely configured through cosmic-settings
• "Dynamic Shortcuts" - Shortcuts requested by an application through the global-shortcut Portal. These may or may not be persisted in some way (e.g. by automatically allowing applications to bind the exactly same shortcut again next time.)

Default Shortcuts are set by cosmic-comp and should likely include most of whats defined in the default-config file today. They could be overridden/replaced by static/dynamic shortcuts at runtime.

One set of open questions regards the "Static Shortcuts". They should be managed via cosmic-config for easy persistence and access for all components.

Open questions:

• Should they be stored by cosmic-comp (and simply edited by cosmic-settings). How would something like binding media-keys to MPRIS work then? Would cosmic-comp start a cli tool and call a dbus-service or something like that?
• Or should they be managed by cosmic-settings-daemon and on launch registered the same way as dynamic shortcuts through the portal are?
  • Whatever protocol is used here, this means the daemon would naturally get callbacks for all shortcuts and could directly issue dbus-requests and handle default apps / multiple implementations properly.
  • I am personally in favor of this approach, but that makes cosmic-comps shortcut customization story pretty bland on it's own and the portal or the settings-daemon practically a requirement in other environments. So this approach likely works best, if we use a commonly used protocol here, to make that dependency less jarring and easily replaceable.

The other set of questions concerns the dynamic shortcuts:

• How should communication work?
  • I don't see a point in adopting the hyprland protocol, as it is very compositor specific and not a lot of tooling exists around it. It might serve as a base for a cosmic-specific protocol though
  • The alternative would be the action binder protocol currently drafted upstream. The problem here is, that it has been long in the works, but isn't ready yet. So if we want to ship something based upon that now, we need to rename it under our own namespace, like we did for cosmic-screencopy, until it is merged upstream.