Iced: Clipboard support?

[Newbytee]

I'm on Linux/X11, and clipboard support seems non-existent. Would definitely be great to have this.

I found this issue: https://github.com/hecrj/iced/issues/36, but it only seems to concern selecting text (which seems to work for me in Iced 0.1), not copying and pasting.

Is anyone working on this? I might take it on if not.

[hecrj]

Currently, we only support pasting (i.e. reading) from a Clipboard. There are plans to support copying (i.e. writing) relatively soon.

I started a window_clipboard crate to experiment and unify different clipboard APIs for GUI applications. There are some on-going discussions there. Feel free to join!

[Newbytee]

Currently, we only support pasting (i.e. reading) from a Clipboard.

Does this require the application using Iced to handle the clipboard itself, or can I somehow have a text field inherently support pasting (via the usual keyboard shortcuts)?

There are plans to support copying (i.e. writing) relatively soon.

Any rough estimate?

I started a window_clipboard crate to experiment and unify different clipboard APIs for GUI applications. There are some on-going discussions there. Feel free to join!

:+1:

[hecrj]

can I somehow have a text field inherently support pasting

This should already work since #132.

Any rough estimate?

Once we figure out a nice, cross-platform API for writing to the clipboard.

[mtkennerly]

@hecrj What if a custom iced_native::Clipboard implementation could be passed to a TextInput, like TextInput::new(...).clipboard(MyClipboard::new())? That way, Iced could support the copy/cut logic and keyboard shortcuts out of the box, but they would just be no-ops unless an app provides a custom clipboard (or until iced_winit's implementation offers write support). This should also allow for unique clipboards, like if you wanted multiple program-specific clipboards in addition to (or instead of) the system one and wanted to switch between them with hotkeys.

iced_native::Clipboard::content() is already specific to strings. I'm not sure how/if you'd envision supporting other data types in the future, but if we can just stick with strings for now, then perhaps the trait could be updated like this:

pub enum Error {
    UnsupportedOperation,
}

pub trait Clipboard {
    fn content(&self) -> Option<String>;
    fn write(&mut self, text: &str) -> Result<(), Error>;
}

iced_winit could just return Err(Error::UnsupportedOperation) for write, meaning the keyboard shortcuts would be no-ops.

For non-string types, perhaps a separate MultimediaClipboard trait could be added in the future if needed, without breaking compatibility for text-only widgets.