Naive clipboard support

[ickshonpe]

Objective

Add a platform-agnostic interface for interacting with the clipboard.

Solution

New crate bevy_clipboard that has a ClipboardPlugin. The clipboard is accessed using methods on the Clipboard resource. It only has two methods get_text and set_text which return Results, with errors if the clipboard is unavailable.

On windows the Clipboard resource is a unit struct and a new arboard clipboard instance is created and dropped for each clipboard access. On unix targets the Clipboard resource holds a clipboard instance it reuses each time.

Doesn't support images or android and wasm targets. Almost everything is done by the arboard crate.

I'm not sure that clipboard support needs its own crate but I wasn't sure where to put it if not.

Testing

Add this system to an app:

fn clipboard_test(mut clipboard: ResMut<Clipboard>) {
    let text = clipboard.get_text().unwrap();
    info!("clipboard contents = {}", text);
    info!("set clipboard text");
    clipboard.set_text("Hello bevy!").unwrap();
    let text = clipboard.get_text().unwrap();
    info!("clipboard contents = {}", text);
}

If working should output:

2025-05-06T22:51:56.918208Z  INFO text: clipboard contents = Hello world!
2025-05-06T22:51:56.918317Z  INFO text: set clipboard text
2025-05-06T22:51:56.918574Z  INFO text: clipboard contents = Hello bevy!

[alice-i-cecile]

Marked as X-Controversial due to a new crate, but I strongly think we need this as part of the engine in some form. Both for games and the editor!

[mockersf]

I don't like the crate for that which is pretty much just a resource wrapping arboard...

And not sure I like the fake resource that can't work on not supported platforms

[MrGVSV]

Question: why can't Clipboard store the string itself? Then use arboard in addition when it is supported?

I guess that only works when setting directly through the resource. But might be an okay tradeoff

[ickshonpe]

I thought about this but felt like it might be confusing for users if copy and paste is only working internally.

[MrGVSV]

What platforms are unsupported? It might be an okay tradeoff to still allow some amount of clipboard behavior

[Henauxg]

arboard seems to support Linux, Mac and Windows. So there's at least Web that is unsupported, and many no_std targets.
I also feel like ultra basic support is still better than no support at all ? Maybe with a warning emitted if the plugin is enabled on an unsupported platform ?

[Henauxg]

I think dropping the Clipboard may not work on Linux ?
See arboard's documentation about platform-specific behaviors (and also issue #88 and PR #89 for more info)

[ickshonpe]

Yeah seems like drop-after-use is only needed on windows.

[ickshonpe]

I don't like the crate for that which is pretty much just a resource wrapping arboard...

This PR is really trivial, but image and android and wasm support will add a lot more complexity. I'm being lazy here, I've got way too many things I working on atm so I was thinking if I just get desktop text clipboard support going someone else will pick this up and fill out the rest of the implementation.

I'm not sure it's an important enough feature to deserve its own crate, but I'm not sure if it belongs in any of the exisiting crates either. Maybe bevy_window but using the clipboard doesn't require a window.

And not sure I like the fake resource that can't work on not supported platforms

The idea is that you can only use the clipboard with a ResMut<Clipboard> to ensure that access is exclusive. Maybe there's a better way to implement it, I'm not sure.

[Henauxg]

For crates candidates, I've had a look and did not find much either. Doesn't fit in bevy_text, nor bevy_input. Could always force it in bevy_utils but that's no great either. There's maybe bevy_app which already has a TerminalCtrlCHandlerPlugin plugin using the ctrlc dependency, but I'm not sure that tying clipboard to App is a good choice.

There's a potential savior in bevy_winit. I've seen that clipboard handling might be on the roadmap for 0.31 or later ? See #162 and #2156
So it may make sense to snuck it into bevy_winit, while waiting for it to be available directly from winit ?