Closed jsparber closed 5 months ago
So looks like the cliboard portal only works for remote sessions, so the implementation would still be pretty hacky. Closing for now.
See: https://gitlab.gnome.org/GNOME/mutter/-/issues/3486#note_2144942
Hi, D-Bus support has been discussed many times already, including in the very issue you've linked.
I'm a GNOME person myself, and I totally agree that not everything needs to be shoved into a Wayland protocol (like the wlroots folks would prefer it); D-Bus is a better solution in many cases.
But: wl-clipboard is not "xdg-clipboard". It's a pair of Wayland clipboard utilities; D-Bus, X11, CFPasteboard, and any other transports are explicitly out of scope. There are separate command-line tools for accessing those; for D-Bus in particular you could probably make a simple script wrapping appropriate gdbus
invocations.
A nice way out of this unfortunate situation would be for Mutter to implement wlr-data-control (or rather, accept the implementation that I have already written, and have been using myself). But that is not going to happen, realistically. Note that wlr-data-control is not a security hole if it's only exposed to non-sandboxed clients (i.e. not Flatpak apps), as other compositors (such as niri!) do it.
wlr-data-control isn't perfect either, by the way: I have a bunch of ideas on how wlr-data-control could be improved/extended, but I wasn't able to convince wlroots folks that these are worthwhile. If, by any chance, you could get Mutter folks interested in collaborating on developing and implementing yet another Wayland clipboard protocol, I'd be glad to work on that from wl-clipboard's side.
It would be nice if
wl-cliboard
could use the the xdg desktop portal: Clipboard whenever it's available instead of the hack currently used when the wlr-data-control isn't implemented (e.g. on Mutter).This would properly address https://github.com/bugaevc/wl-clipboard/issues/90
CC: @sdroege