Weston code: https://cgit.freedesktop.org/wayland/weston/tree/xwayland/dnd.c

Wlroots: https://github.com/swaywm/wlroots/tree/master/xwayland/selection

Awaits following pr to be complete: https://github.com/swaywm/wlroots/pull/841

Selections are the way to go for inter-client data transfers on X and are defined in ICCCM: https://tronche.com/gui/x/icccm/sec-2.html#s-2
General introduction to X11 Selections: https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html

Note the sections about the Selection Manager. This is KSelectionOwner in KWindowSystem, which is currently started on Wayland as well and caches selections so it can be sent to targets even after the source got killed. Supporting this functionality on Wayland would be nice long-term, but short-term I'm willing to give up on it in order to support Xwl<->Wayland dnd.

For selections we currently have the xclipboardsync binary (source in helpers/xclipboardsync). It just connects to the QClipboard of the binary's QApplication and by that catches and provides selections of the CLIPBOARD selection.

For drag and drop we need to support XDND:

• https://www.freedesktop.org/wiki/Specifications/XDND/
• http://johnlindal.wixsite.com/xdnd

It communicates between windows pending dnd operations but in the end it also uses X Selections for the data transfer.

Current status:
Clipboard, selections and Dnd work in general now on my dev branch, but there might be still some memory leaks.

Some observations:

• The Direct Save protocol is used by Chromium, but can't be reasonably well translated to Wayland's DND scheme. But there should always be the normal XDND fallback.
• When an X drag is ongoing some source clients check X internal window stack, but Chromium tries to optimize and goes through _NET_CLIENT_LIST_STACKING if the property exists.
• Firefox and Chromium do not use the text/uri-list target as one would assume, but only support text/x-moz-url and in the case of Firefox additionally _NETSCAPE_URL.
• text/x-moz-url data is sent by both Chromium and Firefox as utf-16.
• Some applications offer the TEXT target atom, others offer text/plain and while on Wayland side both are represented by text/plain they are different on X.

Still missing:

• Support for older versions of the XDND protocol is not yet fully thought through (all my test apps use most recent version 5 though).
• Making the Xwayland part away from the ApplicationWayland class nicer.
• Creating a separate X window for each X to Wl transfer since there can be multiple X windows sending data concurrently to multiple Wayland clients and this way they don't interfere with each other.