Fix screen flicker on Wayland

[iFreilicht]

Fixes #190

The GUIClipboardDaemon created a new Wayland window every ~2 seconds to interact with the clipboard. This steals focus from the currently active window for a very short time, causing context menus and overlays to close. It basically made Clipboard unusable on Wayland.

The simplest strategy of fixing this is to align Linux with all other platforms by only reading data from the clipboard on-demand instead of doing it continuously.

As far as I could tell, this daemon was part of a yet-to-be completed feature, so it feels fine to remove it.

Tested systems

I tested this change on:

• NixOS with KDE Plasma6 Wayland, x86_64
• NixOS with KDE Plasma6 X11, x86_64
• macOS Sequoia, aarch64

If you want to test

With Nix

nix build 'github:iFreilicht/Clipboard?rev=75ff814efddba2b6e9c2da639d1c3360dc09ab13'
cd result/bin
./cb copy "test"

(If you don't have flakes enabled by default, add --extra-experimental-features nix-command --extra-experimental-features flakes to the first command)

Manual

Download my branch, make sure you have all dependencies and tools installed. Then, run

cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build .
./cb copy "test"

[Slackadays]

Unfortunately, this isn't a fix because this behavior enables automatically updating the clip history on platforms where it's supported. That means we need to still keep working in the background, but there are still a couple more options. The first is to use the Special Clipboard API provided by wlroots or to make this background behavior opt-out with maybe something like CLIPBOARD_GUI_ON_DEMAND. Do you mind considering one of these other fixes instead?

[iFreilicht]

I've looked at the wlr_data_control API, and I think it's not a great solution yet because it's marked unstable and so might only create additional work in the future. It would be the most correct solution, though.

Opt-out might be an option, but I feel the most reliable way of implementing this would be to only enable this functionality by default on X11 Linux for now, and add both CLIPBOARD_GUI_DAEMON and CLIPBOARD_GUI_ON_DEMAND so all users by default get the most compatible behavior with their setup. Wayland users can then still try to enable the daemon, maybe it works in some compositors, and X11 users can opt-out if they don't want the tool to monitor for clipboard changes (which might be considered a security risk).

What do you think, does that sound reasonable?

[Slackadays]

Although the opt-out option might be the most stable going into the future, lots of users don't care about customizing software and will just leave it the default. That's why I think it would actually be best to implement the data control API because other clipboard managers also have and they did so long ago, and so any changes to the API would affect all clipboard managers, disincentivizing those changes.