xpra icon
Bug tracker and wiki

Version 21 (modified by Antoine Martin, 5 years ago) (diff)





Clipboard support is an ongoing struggle. One common difficulty with Windows clients is that these platforms only have a single (*) clipboard whereas X11 has three (CLIPBOARD, PRIMARY and SECONDARY), and therefore we need to choose which one to exchange with. On MS Windows, the OS pulls clipboard data as soon as we claim ownership of the selection (see workaround in r3051 + r3075) On OSX, we have to use polling to see client-side changes (see #11)

A more technical issue is to do with the way the clipboard hooks are implemented, using native C code (xpra.gtk_common.gdk_atoms via Cython), which is imported in most platform specific clipboard implementations and also the nested main loop code.

Testing the clipboard

The easiest way to test the clipboard is to use xclip to set and verify the contents of each clipboard:

  • To set the "primary" clipboard contents to the string "_primary_":
    echo _primary_ | xclip -i -selection primary
  • To print the contents of the "primary" clipboard:
    xclip -o -selection primary

Note: on win32, you will need to change the clipboard currently in use to match the one you modify, this must be done before changing the value to ensure it is propagated.

Debugging: with version 0.12 onwards, just add "-d clipboard" to your command line (with older versions set the environment variable: "XPRA_CLIPBOARD_DEBUG=1")

Starting with v0.9.0 there is also a tool which can be used to diagnose clipboard behaviour:

  • GTK_Clipboard_Test.exe on win32
  • gtk_view_clipboard.py on posix

see #272 comment:5 for screenshots and help with that.

Useful Pointers

Here are some pointers:

And here is a good quote from it:

Clipboard sharing and network transparency: It's nearly impossible to make the clipboard shared across different desktop computers. In fact it is possible, but such an implementation would be needlessly difficult and complex. The same can be said of support for virtualization (Qemu, Xen, VMWare). Sharing the clipboard between a virtual machine and the desktop itself is painfully difficult to implement correctly (in case X11 is running on the host operating system).

Source code

  • xpra.clipboard.clipboard_base - the base class for clipboard implementations
  • xpra.clipboard.gdk_clipboard - the gdk clipboard implementation (which requires Cython to build the C parts that allow us to access X11 atoms). It also contains the TranslatedClipboardProtocolHelper which is used by Windows clients to translate the local clipboard to a particular X11 clipboard.

Related tickets

  • #41: when we support concurrent users on the same session, we currently give the clipboard to the first client - doing anything else will be quite tricky
  • #272 win32 multiple clipboards enhancement
  • #318 osx client-to-server clipboard support
  • #273 handle more clipboard formats
  • #274 advanced clipboard filtering
  • #275 handle clipboard large data transfers better
  • #276 limit clipboard direction
  • #452 detect and avoid creating clipboard loops
  • #313 speedup paste
  • #184 clipboard related bug, clipboard can fire at any time... so bugs may appear to come from somewhere else when in fact it is the clipboard that is the source of the problem - to keep in mind
  • #162 very hard to reproduce bug - relied on the list (and their order) of X11 atoms defined, as we tried to parse invalid values as X11 atoms
  • #176 32-bit vs 64-bit structures issue
  • #156 we drop clipboard packets that are too big - rather than causing network problems (bug was that we dropped the connection instead - oops!)
  • #52 another atom name issue, this time with Java apps
  • #8, #84 and #99 (dupe: #104): more clipboard atom problems
  • #11 win32 and osx clipboard ticket (old)