handle clipboard large data transfers better

[totaam]

At present, the limit for clipboard packets is 32KB (see #274), which means that:

• this can cause significant network congestion, delaying all other packets until the data is fully sent - causing problems elsewhere (ie: the damage heuristics to start batching screen updates heavily)
• this delay can cause the user to get confused, wondering why "it is not pasting" and requesting the data again... causing yet more trouble.

Solutions:

• if the clipboard data is large, send it in chunks so we can interleave it with some more regular data (screen updates from server, mouse movements from client, etc) - and maybe even, cancel it altogether if we find that the other end timedout
• as we start sending the clipboard data, notify the client so we can give a visual cue to the user that something is happening (temporarily replace the tray icon with a clipboard icon?).

[totaam]

r2849 builds on r2848 to show to the user that something is happening with the clipboard: we blink the system tray (not on win32 yet) and change it to a clipboard until we receive all the response(s) from the server.

We also bump the clipboard maximum size to 256KB and constify it.

[totaam]

r2850 makes the server tell the client about its pending clipboard requests so we now display the cue no matter which direction the copy+paste operation is from.

Each changeset has details in the commit message - worth a read.

[totaam]

Now that #272 should work, please take a look.

[totaam]

It looks like the bump to 256 KB makes the clipboard big enough to handle pretty much any reasonable or even not-quite-reasonable amount of text.

Currently the clipboard doesn't seem to support even thumbnail-sized image copying or pasting- but it looks like ticket #273 is aiming at dealing with other formats than text.

I think that can wait for 1.0, so I'll go ahead and close this ticket.

[totaam]

Unfortunately, this caused a regression on Ubuntu with appindicator installed: #344

[totaam]

Re-opening because of #448, enough changes there to need re-testing.

The "blink and show clipboard icon in the system tray" is likely to be disabled for 0.10.x

[totaam]

v0.10.x will no longer change the tray icon and tooltip on clipboard requests as of 4630.

afarr, can you please re-test trunk? (win32, osx, appindicator, etc..)
This is related to #318#comment:15

[totaam]

2013-10-29 22:52:53: afarr commented

---

Testing the clipboard on osx 10.6.8, xpra client 0.11.0-4630 (our build) with xpra-0.11.0-1.fc19.x86_64.rpm server side (beta release, fully updated fedora19)... the xpra icon no longer "hops", nor does the clipboard icon overlay it when copies are made on the local client machine.

(As a clarification from ticket #318, with the 10.6.8 osx, when the dock was "hidden" then the icon would "hop" into view... when the dock wasn't hidden, the clipboard icon overlaid it... But, after the session was "grabbed" by another client on another local machine, then "re-grabbed" back by the 10.6.8 machine's client... once that "transfer" had taken place, the xpra icon no longer reacted to copying on the local desktop on the 10.6.8 machine. However, with an osx 10.7.5 machine running the same xpra client version ... the clipboard icon overlaid before and after connection "transfers" identically.)

• Unfotunately, with this new release copies made on the local desktop are not recognized by the client's session clipboard (within the xpra session). Copies to the clipboard within the xpra session paste out to the local desktop apps as expected, but when something is copied to the clipboard from the local desktop the contents of the clipboard-within-xpra do not change- pasting within the xpra session will paste whatever was last copied within the session, effectively creating two different clipboards (primary vs. clipboard?) until a new copy is made within the xpra session... at which point both clipboards re-sync contents again.

• To make matters worse, trying to copy a "relatively" large block of content within the xpra session repeatedly caused the xpra client to crash with the following error message:

2013-10-29 15:12:52,203 unhandled format 0 for clipboard data type NONE
2013-10-29 15:17:39,788 connection closed after 23K packets received (0.1G bytes) and 7K packets sent (0.2M bytes)
2013-10-29 15:17:39,815 Connection lost

When repeated the second and subsequent error messages indicate fewer packets but the client crash behavior is the same:

2013-10-29 15:18:13,686 unhandled format 0 for clipboard data type NONE
2013-10-29 15:18:13,737 connection closed after 223 packets received (0.8M bytes) and 35 packets sent (11K bytes)
2013-10-29 15:18:13,738 Connection lost

This crash was completely reproducible, but did not impact the server session at all (I was able to re-connect to the continuing session and crash the client anew at will).

Repeating with --opengl=off also results in a client crash with packet numbers similar to the second and subsequent crashes with opengl on.

Using the gtk_view_clipboard.py tool It appears that copies to the clipboard within the xpra session are being recorded to both clipboard and primary, but copies from the local client show no change in the clipboard values (and, as one would expect, there is no change in what is pasted).

As a semi-related note, trying to use the xpra gtk_view_keyboard source (and presumably the view_clipboard as well) inside the Python shell included in the Helpers directory produces an import error:

Python 2.6.1 ([r261](../commit/92fee66687a08d8dc86d62e7fc91033c3d2c9424):67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygtk
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named pygtk
>>> 

... despite pygtk being easily (enough) locatable in ...xpra.app/Contents/Resources/lib - a stumbling block that prevents me from checking what might be happening with the clipboard in the local osx environment (though I suppose we can guess about that).

[totaam]

2013-10-30 02:10:16: totaam commented

---

when the dock was "hidden" then the icon would "hop" into view

How do you hide the dock? Do you mean covered by other windows?
[[BR]]

once that "transfer" had taken place, the xpra icon no longer reacted to copying on the local desktop on the 10.6.8 machine

Could be related to the same problem as below (lack of AppKit).
If not, can you please provide logs with XPRA_CLIPBOARD_DEBUG=1
[[BR]]

with this new release copies made on the local desktop are not recognized by the client's session clipboard

Can you clarify which versions/builds work and which ones don't?
This could well be related to a missing AppKit.
[[BR]]

trying to copy a "relatively" large block of content ... caused the xpra client to crash
This was caused by opportunistic clipboard compression (which only fires on data bigger than 256 bytes) and looked like this in the server log:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 373, in _write_format_thread_loop
    self._add_packet_to_queue(*self._get_packet_cb())
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 384, in _add_packet_to_queue
    chunks, proto_flags = self.encode(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 532, in encode
    main_packet, proto_version = self._encoder(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 484, in rencode
    return  rencode_dumps(data), Protocol.FLAGS_RENCODE
  File "rencode.pyx", line 324, in xpra.net.rencode._rencode.dumps (xpra/net/rencode/rencode.c:4019)
  File "rencode.pyx", line 304, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3828)
  File "rencode.pyx", line 244, in xpra.net.rencode._rencode.encode_list (xpra/net/rencode/rencode.c:2841)
  File "rencode.pyx", line 307, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3853)
  File "rencode.pyx", line 256, in xpra.net.rencode._rencode.encode_dict (xpra/net/rencode/rencode.c:3119)
  File "rencode.pyx", line 304, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3828)
  File "rencode.pyx", line 244, in xpra.net.rencode._rencode.encode_list (xpra/net/rencode/rencode.c:2841)
  File "rencode.pyx", line 310, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3879)
Exception: type <class 'xpra.net.protocol.LevelCompressed'> not handled

And this is fixed in r4644 by flattening the "clipboard-token-with-data" packets for OSX clients so that the network encoders don't encounter the compressed data.
The other options would have been to:

• teach the encoders how to inline such data (yuk)
• or disable compression (quickly problematic for text)
  Note: this changes the packet format, which will create incompatibilities between 0.11.x (trunk) pre and post r4644 with OSX clients, just avoid this mix.
  [[BR]]

As a semi-related note, trying to use the xpra gtk_view_keyboard source (and presumably the view_clipboard as well) inside the Python shell included in the Helpers directory produces an import error:

You're using the wrong python.

Either launch from the jhbuild shell, which has its own python installation.
Or follow the comments in #318#comment:4 (use Xpra.app/Contents/Helpers/Python)

r4647 adds a launch wrapper for the keyboard tool:

Xpra.app/Contents/Helpers/Keyboard_Tool

I am not adding one for the clipboard, because the OSX clipboard is so limited and different from the regular ones that the clipboard tool would be useless, and more confusing than anything.

[totaam]

2013-11-14 20:31:01: afarr commented

---

As of 0.11-r4745 there is no "bounce" to the xpra icon when copying/pasting, there is no sign of a clipboard icon overlay, and there is no sign of client closing when copying relatively large blocks of data.

Also, the keyboard tool works quite nicely.

[totaam]

Right, there won't be any dock bouncing anymore as we send the contents with the clipboard owner change packets, so there is never any pending transfers (at least going from server to client) on macosx.

I am confused and a bit tired so I hope I am not missing anything as I close this bug - at last! (feel free to re-open if anything is amiss)