Cloudef / wlc

High-level Wayland compositor library
MIT License
331 stars 58 forks source link

X11 clipboard sync #270

Closed nyorain closed 7 years ago

nyorain commented 7 years ago

This adds (basic) synchronization between the xwayland and wayland clipboard. It also fixes some found bugs in the polymorphic data-source implementation and cleans up some aspects of the xwm implementation (mainly removes the global state).

The xselection implementation is nothing beautiful and can be improved. It implements only the absolutely needed functionality and does not care about the icccm spec too much at places (i.e. the given timestamps are probably not always correct and it does not implement INCR data transfer but this is usually not needed).

It only works for text data on the clipboard at the moment but can be easily extended to further types (is there anything else the clipboard is used for?). Note that it cannot be easily extended to support all types in a generic way though since we have to map the TARGETS atoms from x11 to mime types in wayland (and the other way around) and there is probably no general way to do this. Many applications and toolkits use mime types as x11 targets already though so we might simlpy guess there (not sure if this is a good idea and again, text is probably the only really important clipboard target).

Please tell me if there is anything that has to be done to consider this feature done for now. This would additionally need some further testing it works for me with the wlc example and sway (mainly tested with chromium and termite on the both backends) but this is so ugly/easy to get wrong that all testing is appreciated.

ddevault commented 7 years ago

Quick notes just from reading over your description:

(is there anything else the clipboard is used for?).

Images are pretty common. Also perhaps rich text (i.e. libreoffice).

Many applications and toolkits use mime types as x11 targets already though so we might simlpy guess there (not sure if this is a good idea and again, text is probably the only really important clipboard target).

Maybe we could have a hardcoded list of hairy conversions and then fall back on just copying it over? Do you know what other compositors do?

Syncronization works in both directions, right?

nyorain commented 7 years ago

Synchronization works in both directions. Weston implements only text as well and i have no idea what gnome does (probably something similar to what you are describing). So yes, try some conversions and then fall back sounds like a good idea, should i implement it like that?

ddevault commented 7 years ago

Yep. See if you can at least figure out image data. Try copying it from a wayland web browser and pasting it into gimp.

nyorain commented 7 years ago

Fixed the style issues and implemented the custom conversions with fallback to just offer the atom name as mime type if it might be one (the code checks if the atom name contains a '/' at least to not offer targets like TIMESTAMP or TARGETS which are obviously no mime types and not understand by any wayland application). Still works for me in basic test (chromium, firefox, terminal, etc), was not yet able to test it with images (most applications use filepaths/urls for images anyways).

ddevault commented 7 years ago

Excellent. A quick glance looks good, I will get this tested and merged later today. Great work!

ddevault commented 7 years ago

I tested this with image data and it did not work. Here are some easy steps to reproduce:

  1. Open a web browser with wayland (i.e. env QT_QPA_PLATFORM=wayland-egl qutebrowser) and copy an image to the clipboard (the image, not its url)
  2. Open gimp and file -> create -> from clipboard

That being said, this is better than what we had before. I'm going to merge this now and expect further issues to be resolved in further pull requests.