WIP: Implement hyprland-global-shortcuts-v1

[bbb651]

I made a simple client for testing: https://github.com/bbb651/global-shortcuts-test (and tested that it works correctly in hyprland)

I haven't tested it yet but it should work with the GlobalShortcuts portals with ~/.config/xdg-desktop-portal/portals.conf:

[preferred]
default=gnome
org.freedesktop.impl.portal.GlobalShortcuts=hyprland

Unresolved questions:

• What happens with there are other implementations of the GlobalShortcuts portal? Wlroots stopped adding protocols, ext seems likely to happen at some point, I think they'll be pretty similar (they'll both be following the portal pretty closely) so don't think it'll be hard to support both of them (and maybe remove the hyprland one at some point if clients aren't using it?). Gnome seems more problematic assuming it'll be DBus based, I think there's still value in having supporting a wayland protocol even if we support the Gnome one for layer-shell use cases so I don't think this should be a blocker.
• How does it interact with binds? I'm currently made a Action::TriggerGlobalShortcut action that immediately presses and releases the shortcut, but this doesn't match the capabilities of the protocol (and the GlobalShortcuts portal). Once we have release binds we could have separate Action::PressGlobalShortcut & Action::ReleaseGlobalShortcut actions, which is the most flexible but is a bit verbose. I like the idea of "hold actions" that are continuous instead of discrete and are bound to both an entire bind press and release, this works for other continuous actions like resizing and translating the view, but I'm not sure about a design that plays nice with both multiple actions per bind and release binds.
• Representing the shortcuts as HashMap<(String, String), HyprlandGlobalShortcut> is a bit awkward in some places, the key reference becomes &(String, String) and in niri msg global-shortcuts I think it makes more sense to print them by app id. Hyprland seems to join them with : and store and accepts them like that, this doesn't work correctly for app ids containing : but they are technically invalid. Either way I still prefer separate arguments in the config and cli.

Also currently ipc doesn't quite work (and I've just realized I've broken handling of duplicate shortcuts by creating the HyprlandGlobalShortcutV1 object even when it errors later to try to workaround lifetimes..), the protocol implementation is a bit messy and clone strings a lot and CI fails (something is really wrong with my rust/cargo today, rust-analyzer repeatedly failed to run, it seemed to constantly be doing full rebuilds and it apparently didn't recompile ipc client...).

[YaLTeR]

Haven't looked at the code yet, but: why the Hyprland portal impl + protocol? It would make more sense to support the Mutter API to get it working through the GNOME portal, considering we already use it for screencast. Unless the Mutter API for global shortcuts is somehow much harder to implement in niri?

[bbb651]

I wasn't aware it existed already, I just checked and it looks like it'll make it into Gnome 48, the private api was merged and the portal implementation got a freeze break.

Like I said I think supporting both the mutter api and a privileged wayland protocol for layer-shell and other utilities makes sense (like screensharing), but the mutter one is more important and we should probably wait for an ext protocol, I don't know of clients other than XDGH that use it.

Edit: I was also wrong about an ext protocol being similar to the hyprland one, there is currently an MR for action-binder and it's quite different. Either way supporting only the mutter api right now makes the most sense.