feature request: wayland support

[quininer]

https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing

[aweinstock314]

It looks like https://github.com/vberger/wayland-rs is a widely-used, actively maintained set of bindings for wayland (in contrast to https://github.com/eyolfson/rust-wayland, which was last updated early 2015 and has few downloads on crates.io, though it does seem to be pure-rust).

I'm not sure I'll have time to do this myself, though I'd be glad to review and merge it if you (or someone else) submits a PR (preferably under Apache2 license).

At a high-level sketch of a design, I'd expect a PR to add a wayland_clipboard.rs containing WaylandClipboardContext with an impl of ClipboardProvider (I'll be able to add plumbing for making it part of the default ClipboardContext on systems that have Wayland).

Some discussion on the design (IRC logs):

13:40:14 < aweinstock> is there a #[cfg] for wayland?
13:42:32 < WindowsBunnyNibblerOfErickts> aweinstock: No because wayland isn't an OS or target
13:42:45 < WindowsBunnyNibblerOfErickts> aweinstock: It's just an application that happens to be installed sometimes
13:43:17 < sebk> the features can't be crate-names needs to be fixed.
13:43:40 < WindowsBunnyNibblerOfErickts> sebk: Crate dependencies cause implicit features to be created
13:43:43 < aweinstock> so the right way to do this is to have a feature on my crate for selecting wayland vs x11?
13:44:01 < sebk> (and both?)
13:44:17 < WindowsBunnyNibblerOfErickts> aweinstock: cargo features are not made for mutually exclusive decisions
13:44:27 < WindowsBunnyNibblerOfErickts> aweinstock: cargo features are *only* appropriate for API additions
13:44:49 < WindowsBunnyNibblerOfErickts> enabling a feature can never disable or change functionality, it can only add new functionality
13:45:10 < sebk> i'd add X11/Wayland using feature flags and then select at runtime
13:45:26 < sebk> (which is what winit does)
13:49:30 < aweinstock> the context is rust-clipboard, which is intended to provide platform-agnostic clipboard access (with the callees not having to care much about configuration), so on systems where both x11 and wayland
                       are available, should it try one, then fall back to the other? (is there some other design that makes more sense?)
13:50:31 < sebk> both have independend clipboards
13:51:08 < sebk> so if X11 and wayland are detected, you really need to watch both
13:52:17 < aweinstock> I can see how to do set_clipboard for both, is there a sane way to do get_clipboard for both in a pull-based API?
13:54:30 < WindowsBunnyNibblerOfErickts> aweinstock: If you successfully get the clipboard contents from both wayland and X11 at runtime...
13:54:42 < WindowsBunnyNibblerOfErickts> then uh, throw a temper trantrum
13:55:13 < sebk> (if they differ)
13:55:32 < sebk> WindowsBunnyNibblerOfErickts: that's not an unlikely
13:55:35 < sebk> -an
13:55:50 < Sho> we sync the wayland and xwayland clipboards in kwin
13:56:09 < sebk> that doesn't mean it always works…
13:56:27 < sebk> wayland  -> X11 works for me
13:56:28 < aweinstock> so doing WaylandClipboard.get_contents().or_else(X11Clipboard.get_contents()) should do the right thing in most environments?
13:57:18 < sebk> I don't know anything better
13:57:55 < WindowsBunnyNibblerOfErickts> aweinstock: And provide a platform specific API to get specifically wayland or X11
14:00:12 < aweinstock> WindowsBunnyNibblerOfErickts: as in, expose WaylandClipboard and X11Clipboard as seperate structs, but have their union be aliased to the default ClipboardContext name?

[elinorbgr]

For some more context about this issue, and wayland clipboard handling:

• clipboard handling in wayland has some specificities:
  • wayland has a notion of multiple "seats" (each representing one user), and each seat has its own clipboard
    • In general though, most systems will have one single seat. Multi-seat setups are quite unusual.
  • a wayland client cannot access the clipboard if it does not currently have the focus of the associated seat (any such attempts will be silently ignored by the wayland server)
  • due to that, clipboard on wayland cannot be used independently of the rest of the app, and needs some integration
• wayland servers generally have a X-compatibility setup in the form of XWayland, in this way, the correct way to handle clipboard is to use whichever the app is using, and only it
  • winit for example allows to check whether the app is running on x11 or wayland
  • a wayland app trying to access the X clipboard (or the other way around) will generally result to inconsistent and unreliable results

There has been some work to try and make a crate for handling wayland clipboard (see smithay-clipboard), but these specifics leak into its API.

I think there is a discussion to have about if / how these specifics could be compatible with rust-clipboard cc @trimental

[YaLTeR]

Worth noting that there's also the data-control protocol for Wayland clipboard access implemented primarily by wlroots-based compositors, which is intended strictly for applications which do not spawn windows—that is, terminal clipboard utilities and clipboard managers, etc.

I'm not sure whether this crate is intended for use only by GUI applications. If that is the case, then data-control should not be considered.

[elinorbgr]

It's however important to keep in mind this paragraph from the data-control protocol itself (emphasis mine):

This protocol allows a privileged client to control data devices. In particular, the client will be able to manage the current selection and take the role of a clipboard manager.

Compositors can (and are likely to) restrict access to this protocol to special clients. typically a whitelist from the compositor's configuration. So data-control should not be used as a default implementation just because it is more convenient.