[Request] Support for Klipper (KDE Plasma, X11 & Wayland)

[tulpenkiste]

KDE Plasma uses their own clipboard manager (klipper) and as a result, the string passed into set_text is not accessible via CTRL+V/Super+V.

[complexspaces]

Hey there, thanks for the issue. Can I ask how you tested out arboard in the KDE environment? I was able to reproduce using the hello_world example while using Plasma Wayland, but if I add a call to std::thread::sleep() at the end of the example the text Hello, world! stays in Klipper.

I suspect that this is due to either how data handoff is done in Wayland or maybe the nature of wl-clipboard-rs using a temporary file for clipboard contents, and clearing everything away before klipper has a chance to request a file descriptor to make a copy from. I'm hoping that knowing your use case might help figure out the current behavior.

[tulpenkiste]

Hi, I tested both arboard and another clipboard library (cli clipboard) via:

// rs
ctx.set_text(password.clone());

Neither of them would send the text into the kde clipboard.
However, I did manage to create a workaround as klipper does use xclip. The work around is the following:

// rs
if cfg!(unix) {
	// Create pipe
	let mut pipe = Command::new("echo").arg(&password).stdout(Stdio::piped()).spawn().unwrap();

	if let Some(pipe_out) = pipe.stdout.take() {
		// Ok, copy
		let mut out = Command::new("xclip").arg("-selection").arg("clipboard").stdin(pipe_out).spawn().unwrap();
			
		match out.wait() {
			Ok(s) => {
				if s.success() {
					try_set_text = false;
				} else {
					eprintln!("Failed to copy to xclip's clipboard");
				}
			}
			Err(e) => {
				eprintln!("Failed to run xclip, error: {}", e);
			}
		}
	} else {
		eprintln!("Failed to take pipe stdout");
	}
}

[SergioRibera]

I just came because I am having the same problem in a project I have, basically only allows to paste the items that have been copied from arboard but while the application is still open, as soon as it closes it loses all the items that have been copied, this is good for a clipboard manager, but not for applications that want to consume the clipboard, is there any solution from the library?

Note: I have only been able to test this on linux

[complexspaces]

...However, I did manage to create a workaround as klipper does use xclip. The work around is the following:

That's interesting, @tulpenkiste, thanks for sharing. So Klipper persistently stores the data you pipe via xclip?

...basically only allows to paste the items that have been copied from arboard but while the application is still open, as soon as it closes it loses all the items that have been copied

This is, as far as I know, a fundamental limitation of the clipboard of X11. Data copied to the clipboard lives inside the copiers process and gets requested by other apps on-demand via window messages. This is also one of the main reasons clipboard managers exist: to act as a persistent buffer to other applications which may be opening or closing often.

We also implemented a wait function to help with this situation. It will block the current thread until something else has replaced the clipboard contents. I don't think that's what either of you want though, so it is only a reference point.

As far as I know, arboard implements the correct X11 protocols to handoff data to the clipboard manager, and upon dropping the last Clipboard struct in your app arboard will attempt to notify the manager, if any, that it wants to handoff data.

@SergioRibera May I ask you to try running your app with RUST_LOG=trace (or the equivalent for just arboard's logs) to see if anything appears?

[SergioRibera]

Of course, here I leave you the logs that my application launched, apparently it happens what you say, then I dare to say that this is a problem that only occurs in distributions that do not have an integrated or external Clipboard Manager, I find it curious the truth, I would expect it to work otherwise

[tulpenkiste]

That's interesting, @tulpenkiste, thanks for sharing. So Klipper persistently stores the data you pipe via xclip?

Yes, it will persistently store data piped into xclip.