wl-paste --watch: support multiple MIME types?

[c4rlo]

Currently, wl-paste --watch only makes a single representation of the data available to the program, based on the MIME type selected with --type.

Would it make sense to make multiple/all MIME type representations available? That would make it easy to enhance clipboard managers like clipman to maintain them all in their history, rather than only maintaining the plain text versions. And in particular, it would make it easy to implement a more comprehensive workaround for the "clipboard is cleared when client exits" issue (I'm aware of related discussion in #93).

Simplest design I can think of: wl-paste --watch-all PROGRAM invokes PROGRAM with the list of available MIME types as arguments, and with the corresponding file descriptors made available to it in the same order beginning from fd 3.

Alternatively, if we want to be more consistent with the proposal in #93 that makes use of environment variables, we could communicate the MIME types separated by newlines in an environment variable, e.g. CLIPBOARD_MIMETYPES, and optionally perhaps we could have CLIPBOARD_FDS listing the corresponding file descriptors.

[YaLTeR]

Hey! As far as I can tell, there are two main problems with providing several MIME types.

1. Applications generally offer a wide range of types for the content, performing the conversion upon request. This is best visible when copying images, e.g. copying an image in Firefox results in these MIME types:

   image/tiff
   text/ico
   image/icon
   image/ico
   application/ico
   image/vnd.microsoft.icon
   image/x-win-bitmap
   image/x-ico
   image/x-icon
   image/x-MS-bmp
   image/x-bmp
   image/bmp
   image/jpeg
   image/png
   text/_moz_htmlcontext
   text/_moz_htmlinfo
   text/html

   If wl-paste would request each of those types, it'll result in a lot of conversions happening to return a lot of versions of the same image. This is hardly what you usually want and might even result in short freezes every time you copy an image. There's no way for wl-paste to know which format is the "original" one (if there even is an original format).

2. Functionality like wl-copy --paste-once also offers text in a few different MIME types, but as soon as wl-paste would try to open a pipe for a single (perhaps lossy) type all others disappear.

[c4rlo]

Good points.

1. I guess I was thinking the program invoked by wl-paste could pick and choose which file descriptor(s) it wants to read from, based on which MIME types are available. E.g. with the above list, it might choose to only copy image/jpeg and image/png or something.

   But I guess by the time it has received the fd, the copying process (Firefox in the example) may well have done a lot of the conversion work already.

   As a next-best option, we could pass a list of MIME types we are interested in to wl-paste so the filtering can happen early on, before we request the fds. Such a list would be a compromise between trying to include the most commonly used MIME types while also being short enough to minimize the conversion work.

2. My impression is that wl-copy --paste-once is a very unusual case and that programs would normally stick around to allow multiple pastes. Still, I don't see it as a major issue; the program invoked by wl-paste should just iterate over the fds in preference order and be prepared to handle errors properly.

[YaLTeR]

But I guess by the time it has received the fd, the copying process (Firefox in the example) may well have done a lot of the conversion work already.

Yeah, I imagine applications do the conversion even before they hand out the fd to the compositor.

Such a list would be a compromise between trying to include the most commonly used MIME types while also being short enough to minimize the conversion work.

I'm not sure this can quite work unfortunately. Some applications do export only a single format (e.g. wl-copy < image.png will result only in a single MIME type), so you do want a set of most common images (PNG, JPG, BMP, TIFF) which is already a fair share of conversions.

The program invoked by wl-paste should just iterate over the fds in preference order and be prepared to handle errors properly.

I'm afraid that by the time wl-paste gets the first fd all others are already inaccessible. But I agree it's not a particularly usual case.