Write support; dependencies

[dhardy]

Hey, I started looking into adding write support (still only for strings). But this immediately brought up some questions about dependencies:

• why not uses https://github.com/quininer/x11-clipboard instead of having your own implementation?
• what exactly is the point of the wayland wrapper crate?

If you have no objections I might start by ripping out those.

Also, I was going to go with fn write(&self, string: std::borrow::Cow<str>) -> Result<(), Box<dyn Error>>, though given that clipboard-win is the only backend not requiring an allocated string anyway, I'm less sure if it's worth it.

[hecrj]

Hey!

why not uses https://github.com/quininer/x11-clipboard instead of having your own implementation?

IIRC, x11-clipboard has some issues:

• It always enables the xfixes feature which increases the amount of external dependencies. I was able to get it working without it, but I am unsure whether this had undesired consequences or not.
• It has a hardcoded POLL_DURATION of 50 ms. Therefore, reading the clipboard is always unnecessarily very slow.
• It spawns a new thread every time you call Clipboard::new, as a side-effect.

I believe these could be fixed and contributed back, but I think it's best to have a good amount of control for fast-prototyping as we figure things out.

what exactly is the point of the wayland wrapper crate?

More or less the same reasoning. I'd like to get rid of most of the dependencies of smithay_clipboard. Take a look:

window_clipboard v0.1.1 (/home/hector/projects/window_clipboard)
├── clipboard_wayland v0.1.0 (/home/hector/projects/window_clipboard/wayland)
│   └── smithay-clipboard v0.3.6
│       ├── nix v0.14.1
│       │   ├── bitflags v1.2.1
│       │   ├── cfg-if v0.1.10
│       │   ├── libc v0.2.66
│       │   └── void v1.0.2
│       └── smithay-client-toolkit v0.6.6
│           ├── andrew v0.2.1
│           │   ├── bitflags v1.2.1 (*)
│           │   ├── line_drawing v0.7.0
│           │   │   └── num-traits v0.2.10
│           │   │       [build-dependencies]
│           │   │       └── autocfg v0.1.7
│           │   ├── rusttype v0.7.9
│           │   │   └── rusttype v0.8.2
│           │   │       ├── approx v0.3.2
│           │   │       │   └── num-traits v0.2.10 (*)
│           │   │       ├── arrayvec v0.5.1
│           │   │       ├── ordered-float v1.0.2
│           │   │       │   └── num-traits v0.2.10 (*)
│           │   │       └── stb_truetype v0.3.1
│           │   │           └── byteorder v1.3.2
│           │   ├── walkdir v2.2.9
│           │   │   └── same-file v1.0.5
│           │   ├── xdg v2.2.0
│           │   └── xml-rs v0.8.0
│           ├── bitflags v1.2.1 (*)
│           ├── dlib v0.4.1
│           │   └── libloading v0.5.2
│           │       [build-dependencies]
│           │       └── cc v1.0.48
│           ├── lazy_static v1.4.0
│           ├── memmap v0.7.0
│           │   └── libc v0.2.66 (*)
│           ├── nix v0.14.1 (*)
│           ├── wayland-client v0.23.6
│           │   ├── bitflags v1.2.1 (*)
│           │   ├── calloop v0.4.4
│           │   │   ├── mio v0.6.21
│           │   │   │   ├── cfg-if v0.1.10 (*)
│           │   │   │   ├── iovec v0.1.4
│           │   │   │   │   └── libc v0.2.66 (*)
│           │   │   │   ├── libc v0.2.66 (*)
│           │   │   │   ├── log v0.4.8
│           │   │   │   │   └── cfg-if v0.1.10 (*)
│           │   │   │   ├── net2 v0.2.33
│           │   │   │   │   ├── cfg-if v0.1.10 (*)
│           │   │   │   │   └── libc v0.2.66 (*)
│           │   │   │   └── slab v0.4.2
│           │   │   ├── mio-extras v2.0.6
│           │   │   │   ├── lazycell v1.2.1
│           │   │   │   ├── log v0.4.8 (*)
│           │   │   │   ├── mio v0.6.21 (*)
│           │   │   │   └── slab v0.4.2 (*)
│           │   │   └── nix v0.14.1 (*)
│           │   ├── downcast-rs v1.1.1
│           │   ├── libc v0.2.66 (*)
│           │   ├── mio v0.6.21 (*)
│           │   ├── nix v0.14.1 (*)
│           │   ├── wayland-commons v0.23.6
│           │   │   ├── nix v0.14.1 (*)
│           │   │   └── wayland-sys v0.23.6
│           │   │       ├── dlib v0.4.1 (*)
│           │   │       └── lazy_static v1.4.0 (*)
│           │   └── wayland-sys v0.23.6 (*)
│           │   [build-dependencies]
│           │   └── wayland-scanner v0.23.6
│           │       ├── proc-macro2 v0.4.30
│           │       │   └── unicode-xid v0.1.0
│           │       ├── quote v0.6.13
│           │       │   └── proc-macro2 v0.4.30 (*)
│           │       └── xml-rs v0.8.0 (*)
│           └── wayland-protocols v0.23.6
│               ├── bitflags v1.2.1 (*)
│               ├── wayland-client v0.23.6 (*)
│               └── wayland-commons v0.23.6 (*)
│               [build-dependencies]
│               └── wayland-scanner v0.23.6 (*)
│           [dev-dependencies]
│           └── wayland-client v0.23.6 (*)

Basically, I believe there is a lot of coordination that needs to happen for a viable library like this to exist. The plan is to experiment here and contribute back if possible.

If you have no objections I might start by ripping out those.

That'd be great. Writing the clipboard in X11 is quite involved, as we need to run some kind of server that responds to paste requests from other windows. May be interesting to consider using futures...

We should also figure out eventually how to deal with copy/pasting other kinds of data (like images, files, etc.) and how to unify all the platforms behind a single, nice API.

[dhardy]

Starting to regret this... X11 clipboard functionality is unintuitive and badly documented.

First point, I guess, is scope and platform differences:

• X11 has the PRIMARY selection buffer; I don't see much interest in this (can be added later if needed, but would probably want a different API anyway)
• X11 (and probably Wayland for special apps) allows monitoring for clipboard update events
• X11 and Wayland are expected to host and serve clipboard contents; Win and Mac write to a shared data store
• Windows allows querying of which clipboard actions are currently possible (for some other platforms, we could query whether the current item is available in a specific format)
• Mac OS and Wayland appear to support additional data-sharing "ports"

All platforms appear to support multiple formats for reads and writes:

• Android has text, URI, and "Intent"
• MacOS supports a fixed list
• Windows supports standard types and registering custom types
• Linux platforms uses MIME types

Perhaps the best approach is to provide an enum of common types and an API for usage of an arbitrary MIME type. This implies that data transfer uses only byte-arrays and higher-level functions for String and maybe some other fixed types would be useful.

Clipboard reads via futures: as far as I understand, this would only be applicable to Linux platforms, and it's only real purpose is to hide the lag between request and receiving clipboard contents if the application can do other work in the mean time. I haven't much experience with async models, but the extra complexity for little-used functionality doesn't sound attractive: I don't expect many apps will be able to put it to much use (e.g. an input field must complete a paste action before processing other input anyway). (There is also another approach to hiding this lag: pro-actively copy clipboard content whenever updated, at least for text. On Wayland this only happens with keyboard focus and we could apply the same limit on X11, so it's not as much overhead as it first sounds. But maybe your current 3-second timeout isn't such a bad option.)

[dhardy]

More about async: Android's URIs are a form of indirect data access, though it sounds like they are broken in practice, so it may only be interesting to support sub-sets such as URLs. This is basically text anyway. Window's SetClipboardData supports usage with a null data parameter, implying a requirement for communication with the providing app.

Maybe it's useful to use an async API for non-text data, but not for the higher-level read/write String API I think.

[dhardy]

It always enables the xfixes feature which increases the amount of external dependencies. I was able to get it working without it, but I am unsure whether this had undesired consequences or not.

Seems to me that this has no effect on dependencies? Anyway, xfixes was only used for the load_wait function, which it seems we don't need.

[elinorbgr]

More or less the same reasoning. I'd like to get rid of most of the dependencies of smithay_clipboard.

FYI, smithay-clipboard needs an update/refactor (to wayland-rs 0.25 mainly), and doing so should allow to remove a large part of its dependencies.