Clipboard support beyond text/plain

[WhyNotHugo]

Looking at the API, it seems that clipboard support only works for text/plain and no other mime type (e.g.: no files, no images, etc). I guess it's fine for the simplest use case when only plain text is copying, but it's generally quite limited.

It's also not possible to determine if the clipboard is taken or not (e.g.: a "paste" button should be disabled if there's nothing in the clipboard, but this cannot be determined right now).

I didn't find any issues discussing this, so figured I'd open one to open discussion on the topic. In general, and application will want to:

• Take ownership of the clipboard, specifying mime-types.
  • The current API only supports text/plain, but anything else should be valid too.
  • Taking ownership of the clipboard should not require supplying the clipboard data right away. If an image is being copied, the application will want take ownership of the clipboard and may announce it can send out image/png, image/jpeg and text/uri-list. Encoding and serialisation will only happen when pasting, and only to the desired format.
• Receive events when another application pastes.
  • Serialisation of data into the right mime-type should be done at this point. E.g.: if I copy an image file, pasting into GIMP will require that it be encoded into PNG, but pasting into a file manager will just require that the application supply the uri-list.
• Receive events when another application takes ownership of the clipboard (e.g.: to enable a "paste" button).

[WhyNotHugo]

My proposal is closely based on how clipboard works on Wayland. I'd be curious to hear if macOS/Windows/Android are compatible with such a flow, or how they solve these issues.

Should also be noted that both Wayland and Xorg have two clipboards. I don't thing any other platform does too. A trait Selection for all operations might be a good interface, and then simply have two implementations: Clipboard and Primary, to map to the two clipboards. The second implementation can be marked platform specific, so can sit behind a feature/cfg, avoiding API issues on incompatible platforms.

[WhyNotHugo]

I see that window_clipboard is used under the hood. From what I can tell, its API is designed to only support copying and pasting short strings.

Under the hood window_clipboard uses smithay-clipboard, which is also designed with a similar premise in mind.

Both libraries also have a rather unusual model in that they expect all computation to be done before taking a selection. This results in [very little] unnecessary work when copying short texts, but would be quite substantial when copying images or videos or larger objects.

My initial idea was to try and implement this outside of iced as some for of extension (at least as a PoC), but that doesn't seem to be possible since there's no way to access the underlying wayland connection.

I'm considering addressing this feature, but I'm not sure where to start. There's three levels of abstraction here which would need to be re-implemented almost entirely since their API is orthogonal to clipboard itself.

I'd appreciate hearing some thoughts/guidance here.

[WhyNotHugo]

It might also make sense to wait and see if rust-windowing/winit#2156 gets a green light.