clipboard data transfer api

[timon-schelling]

Add ActiveEventLoop::clipboard and ActiveEventLoop::set_clipboard for
interacting with the system clipboard through the data transfer API, implemented on Wayland and macOS.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

Follow-up of #4571

Addition to public API consists of two new methods on ActiveEventLoop, both defaulting to NotSupported:

fn clipboard(&self) -> Result<Option<DataTransferId>, RequestError>;
fn set_clipboard(&self, send_data: Box<dyn DataTransferSend>) -> Result<(), RequestError>;

Works like the DnD API. clipboard() gives you a DataTransferId, or None if
the clipboard is empty. Pass it to data_transfer() for the types and
fetch_data_transfer() for the data, which arrives as DataTransferReceived.
set_clipboard() takes a DataTransferSend, encoded lazily when another app
asks for a type, and dropped when someone else takes over the clipboard.

Tested by clipboard example: press C to copy, V to paste, logs the advertised types.
Cross-checked against a browser on hyprland ,niri and kwin.
Also tested in Graphite's desktop app.

Other changes:

• winit-wayland dnd module is renamed to data_transfer, and DndState to
  DataTransferState (wayland: rename dnd module to data_transfer)
• Fixes pre-existing bug where a completed fetch did not set dispatched_events (wayland: mark dispatched events when a data transfer fetch completes)

[ogoffart]

Thanks a lot for working on this.

One problem with the API is that this doesn't support multiple clipboard like the middle-click paste vs ctrl+c/v.

I'm thinking the clipboard and set_clipboard functions should take an enum telling what keyboard we want.

[timon-schelling]

Thanks a lot for working on this.

One problem with the API is that this doesn't support multiple clipboard like the middle-click paste vs ctrl+c/v.

I'm thinking the clipboard and set_clipboard functions should take an enum telling what keyboard we want.

Thank for the review.
Assuming you mean clipboard not keyboard.

Isn't the primary selection just a Linux thing?
I assumed that it should only be accessible via platform extension trait and that it should not really influence the main API design?

If it should be part of the general API I would also suggest taking an enum with Clipboard::Selection and Clipboard::Primary.

[ogoffart]

Yes, I meant clipboard.
Yes, it is a linux thing.
Selection and Primary are the same thing.
But yes, an enum such as Clipboard::Selection and Clipboard::Clipboard. (i'm not very good at naming things)

[timon-schelling]

Yes, I meant clipboard.
Yes, it is a linux thing.
Selection and Primary are the same thing.
But yes, an enum such as Clipboard::Selection and Clipboard::Clipboard. (i'm not very good at naming things)

An you would prefer that being part of the cross platform api (would be easier to implement I guess)?
And not a ActiveEventLoopClipboardPrimaryExt:: clipboard_primary?

If it should be a cross platform thing what should platforms that don't have the primary selection do? Return unsupported?

[kchibisov]

I think one other point is that this API should be brought to every platform that is supported by other clipboard crates, so x11/wayland/windows/macOS at least, so users who rely on special crates for clipboard can just replace them with winit clipboard...

And yeah, on linux we'd need an extra trait for set_primary_clipboard etc,

[timon-schelling]

I'm working on/thinking about the mac implementation, and I could also work on x11 (my testing would be limited to Xwayland) but not sure when I would be able to work on Windows, likely better if someone else with more Windows knowledge works on that.

Personally I would prefer every platform being in it's own (stacked) PR but if maintainers prefer this being one giant PR sure.

And I will add a trait for primary selection, definitely the shape I prefer.

[timon-schelling]

appkit implementation is now in shape I'm happy with, less complicated than initially anticipated. I'm not making good progress with x11 though and haven't looked much into the windows side.