Split from #272
Some Desktop Environments (win32, gnome3) or applications within cause repeated requests for the same clipboard contents:
do_selection_get(<GtkSelectionData at 0x7fff34d2e580>,0,183747806) \ calling selection_data.set(UTF8_STRING, 8, <type 'str'>:6) do_selection_request_event(<gtk.gdk.Event at 0x3bad918: GDK_SELECTION_REQUEST \ selection=CLIPBOARD, target=UTF8_STRING, property=GDK_SELECTION>) target for CLIPBOARD: 'UTF8_STRING' do_selection_request_event(<gtk.gdk.Event at 0x3bad918: GDK_SELECTION_REQUEST \ selection=CLIPBOARD, target=UTF8_STRING, property=GDK_SELECTION>) target=UTF8_STRING, selection=CLIPBOARD do_selection_get(<GtkSelectionData at 0x7fff34d2e580>, 0, 183748319) selection=CLIPBOARD get clipboard from remote handler id=74 process clipboard packet type=clipboard-contents process clipboard contents, selection=CLIPBOARD, type=UTF8_STRING, format=8 _munge_wire_selection_to_raw(bytes, UTF8_STRING, 8, <type 'str'>:6:['h', 'e', 'l', 'l', 'o', '\n']) wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data)=6 clipboard wire -> raw: ('UTF8_STRING', 8, 'bytes', 'hello\n') -> 'hello\n' got clipboard contents(74)=6 (type=UTF8_STRING, format=8) 2013-04-04 14:25:50,941 get clipboard from remote result(74)= \ {'data': 'hello\n', 'type': 'UTF8_STRING', 'format': 8}
This can easily be tested by running tests.xpra.test_clipboard
Now that we send the token with every ownership request (r3051), we may be able to cache the response until the contents change again? (per encoding type obviously) Or maybe monitor the contents ourselves (the same way client apps do), and send the contents only when changed.
I was wrong: I believe this was caused by the fact that we were sending the token repeatedly since r3051, this has been fixed in r3075
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/307