Basic clipboard support#19106
Conversation
Enabled with the `bevy_clipboard` feature. Supports setting and getting text to and from the clipboard. Only supports desktop targets.
Enabled with the `bevy_clipboard` feature. Supports setting and getting text to and from the clipboard. Only supports desktop targets.
|
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! |
|
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 |
| &mut self, | ||
| text: T, | ||
| ) -> Result<(), arboard::Error> { | ||
| arboard::Clipboard::new().and_then(|mut clipboard| clipboard.set_text(text)) |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Yeah seems like drop-after-use is only needed on windows.
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 exis
The intent is that you can only use the clipboard with a |
Co-authored-by: Gilles Henaux <ghx_github_priv@fastmail.com>
* On unix targets an instance of `arboard::Clipboard` is stored in the `Clipboard` resource. * Removed the desktop and dummy modules. * Made `arboard` dependency conditional.
|
For crates candidates, I've had a look and did not find much either. Doesn't fit in There's a potential savior in |
It'd be ideal if winit just supported it and we didn't have to do anything but I don't like the idea of adding it to the winit crate before they have some built in support, it seems like a lie. And it might still need a separate solution when targeting wasm32? |
|
Okay, I think this is finally ready!
@ickshonpe, this is ready to merge once my changes have your approval. |
| @@ -0,0 +1,227 @@ | |||
| //! This example demonstrates accessing the clipboard to retrieve and display text. | |||
There was a problem hiding this comment.
Yeah I made this example quickly without any thought just as proof it works. It's not necessary
once the clipboard is hooked up to widgets that can use it.
| // Defaults selected to match `Text::default()` | ||
| editor: PlainEditor::new(100.), | ||
| pending_edits: Vec::new(), | ||
| pending_paste: None, |
There was a problem hiding this comment.
In bevy_ui_text_input it queues a PasteDeferred(ClipboardRead) in the editor actions buffer so there isn't a need to store it on a field. Then if the result is still pending it doesn't process any more actions and leaves the PasteDeferred on top of the queue to be processed again the next frame. The pending field approach seems a bit simpler, but we might want to switch to the other approach later as it seems unpleasant having bevy_text depend on bevy_clipboard and there might be other reasons we'd want to handle cut and paste at the widget level (pasting images inline into a text input maybe?).
There was a problem hiding this comment.
I can't remember what they were right now, but I'm certain there were other advantages to managing the TextEdit queue at the widget level, not at a lower level from bevy_text. It's out of scope for this PR though, the pending_paste design is fine for now.
There was a problem hiding this comment.
Yeah, happy to explore that in follow-up. I agree that bevy_text -> bevy_clipboard is a bit unpleasant as a dependency.
|
can't approve my own pull request, but 👍 |
Objective
Add a platform-agnostic interface for interacting with the clipboard.
Solution
New crate
bevy_clipboardwith aClipboardPluginthat adds aClipboardresource. The clipboard is accessed using the methodsfetch_text,fetch_image,set_textandset_imageon theClipboardresource.fetch_textreturns aClipboardReadwith apoll_resultmethod that's used to get the actual value once it's ready.The
windowsanduniximplementations both use thearboardcrate. On windows theClipboardresource is a unit struct and a new arboard clipboard instance is created and dropped for each clipboard access. On unix targets theClipboardresource holds a clipboard instance it reuses each time. On both targets thefetch_*andset_*methods work instantly.On
wasm32Clipboardis a unit struct. Thefetch_textandset_textfunctions spawn async tasks. The task spawned byfetch_textupdates the shared arc mutex option once the future is evaluated to get the clipboard text. There is no image support onwasm32.Everything seems to work but it feels like the design is a bit clumsy and not very idiomatic. I don't tend to do much asynchronous programming, maybe a reviewer can suggest an improved construction.
I also added an alternative
fetch_text_asyncfunction for async access that returns aResult<String, ClipboardError>future.Notes
Testing
The PR includes a basic example
clipboardthat can be used for testing.The image display will only work if the image is already in the clipboard before the example starts.