xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#176 closed defect (fixed)

clipboard doesn't work

Reported by: onlyjob Owned by: Antoine Martin
Priority: critical Milestone: 0.5
Component: core Version: trunk
Keywords: Cc:

Description

I'm struggling to get clipboard working in 0.4.1:

On Debian Wheezy (both on server and client) copying text to clipboard (either from menu or keyboard) blanks clipboard contents of the remote machine.

Let's say I select and copy something in remote application, then trying to paste to local application: it pastes nothing and previous clipboard content disappears.

Exactly the same behaviour can be observed the other way: when I copy text to clipboard from local application, clipboard contents of remote application disappear.

Any ideas?

Thank you.

Attachments (2)

fix-clipboard.patch (2.0 KB) - added by onlyjob 5 years ago.
patch: partial revert of r1230
fix-clipboard.diff (728 bytes) - added by أحمد المحمودي 5 years ago.

Download all attachments as: .zip

Change History (29)

comment:1 Changed 5 years ago by Antoine Martin

Status: newaccepted

Changing:

#debug = log.info
debug = log.debug

to:

debug = log.info
#debug = log.debug

in clipboard_base.py can give us a lot more debug diagnostics messages.

I will try what you describe as soon as I can (about a week).
Bear in mind that not all clipboard content types can be serialized and sent over to the other end, that some applications do weird things (Qt apps in particular IIRC), that clipboard managers simply break havoc by constantly requesting the contents of the clipboard, etc...
Which app did you have problems with? Or was this all apps?

comment:2 Changed 5 years ago by onlyjob

Apparently this is a regression because 0.4.0 works perfectly.

comment:3 Changed 5 years ago by Antoine Martin

Hmm, that's odd, all I can see that is clipboard related in 0.4.1:

  • r1230 which is meant to fix x11 long/integer packing on 64-bit platforms - are both client and server 64-bit?
  • r1234 which should only affect platforms without the x11 bindings (ie: win32)
  • r1220 which fixes a typo which was preventing the x11 clipboard code from firing for x11 atoms

There are some further fixes due for 0.4.2:

  • r1310 which should only affect platforms without the x11 bindings (ie: win32)
  • r1274 and r1278 which improve keyboard support for win32

comment:4 Changed 5 years ago by onlyjob

Thanks for hints.

I reckon something went wrong in r1230 - I reverted all changes introduced to

xpra/xposix/xclipboard.py

with the attached patch and it fixed the problem.

Yes, both machines are amd64, sorry for not mentioning it.

Cheers,
Dmitry.

Changed 5 years ago by onlyjob

Attachment: fix-clipboard.patch added

patch: partial revert of r1230

Changed 5 years ago by أحمد المحمودي

Attachment: fix-clipboard.diff added

comment:5 Changed 5 years ago by أحمد المحمودي

I think the patch can be reduced as per fix-clipboard.diff (note: hand crafted diff file, but the idea should be clear)

comment:6 Changed 5 years ago by Antoine Martin

Hmm, there is something odd going on here.
We can't just change the struct.pack without changing the corresponding struct.unpack - this is also used in gdk_clipboard.py for atoms and fixes known bugs.

Also, according to #11 this changeset fixes a warning which does look like a size issue (see 11#comment:3)

And obviously there's the actual X11 docs, see for example:

  • XGetWindowProperty: "Returns the data in the specified format. If the returned format is 8, the returned data is represented as a char array. If the returned format is 16, the returned data is represented as a array of short int type and should be cast to that type to obtain the elements. If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes)."
  • gdk3-Properties-and-Atoms: "A property has an associated format, an integer describing how many bits are in each unit of data inside the property. It must be 8, 16, or 32. When data is transferred between the server and client, if they are of different endianesses it will be byteswapped as necessary according to the format of the property. Note that on the client side, properties of format 32 will be stored with one unit per long, even if a long integer has more than 32 bits on the platform."

Now the latter is confusing me slightly since it talks about padding 32 bits rather than packing into 64... I think this needs looking into by placing know values in there and seeing how they're actually represented.

comment:7 Changed 5 years ago by onlyjob

I'll be happy to help testing this issue when you realise the best way to fix it. :)

comment:8 Changed 5 years ago by Antoine Martin

Thanks - if you can provide log samples from both client and server with debug enabled for clipboard as per comment:1, that may allow me to fix the bug sooner (since I'm not seeing the problem here on my 64-bit laptop - tried both trunk and 0.4.x branch).
Also, please apply the debug change in r1314, or even better, test using trunk to also check if the bug is still present there (just in case - also the debug output in trunk shows the event time which is helpful for piecing things back together).

comment:9 Changed 5 years ago by onlyjob

Here it is:

## 0.4.1 (unpatched, both server and client) do NOT work:

### Paste to remote application @client:

process clipboard packet type=clipboard-request
process clipboard request, request_id=0, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
get_contents(TARGETS,<function got_contents at 0x24a0b18>)
got_contents(ATOM,32,72)

### Paste to remote application @server:

do_selection_request_event(<gtk.gdk.Event at 0x1888be8: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>)
do_selection_get(<GtkSelectionData at 0x7fffddc50440>,0,390684085)
get clipboard from remote handler id=0
process clipboard packet type=clipboard-contents
process clipboard contents, selection=CLIPBOARD, type=ATOM, format=32
clipboard wire -> raw: ('ATOM', 32, 'atoms', ['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS']) -> '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00'
got clipboard contents(0)=36 (type=ATOM, format=32)
get clipboard from remote result(0)={'data': '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00', 'type': 'ATOM', 'format': 32}
do_selection_get(<GtkSelectionData at 0x7fffddc50440>,0,390684085) calling selection_data.set(ATOM,32,36)
do_selection_request_event(<gtk.gdk.Event at 0x1888be8: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>)

As far as I can see all applications are affected.

Also I noticed this may be a server-side issue: if I connect to xpra 0.4.1 that I patched by reverting xpra/xposix/xclipboard.py to 0.4.0 state from unpatched 0.4.1 clipboard works both ways.

Here is a client log for such case:

### Copy to clipboard @client:

do_selection_clear_event(<gtk.gdk.Event at 0x17bbfd0: GDK_SELECTION_CLEAR selection=PRIMARY, target=, property=>) selection=PRIMARY
send clipboard token: PRIMARY
do_selection_clear_event(<gtk.gdk.Event at 0x17bbfd0: GDK_SELECTION_CLEAR selection=CLIPBOARD, target=, property=>) selection=CLIPBOARD
send clipboard token: CLIPBOARD

### Paste to remote application @client (works):

process clipboard packet type=clipboard-request
process clipboard request, request_id=11, selection=CLIPBOARD, local name=CLIPBOARD, target=UTF8_STRING
get_contents(UTF8_STRING,<function got_contents at 0x18517d0>)
got_contents(UTF8_STRING,8,5)

I will test trunk and report ASAP.

Cheers,
Dmitry.

Last edited 5 years ago by onlyjob (previous) (diff)

comment:10 Changed 5 years ago by onlyjob

### trunk r1314 both server and client (do NOT work)

## Server log (paste to remote app):

2012-08-12 18:36:57,453 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>) 
2012-08-12 18:36:57,455 target for CLIPBOARD: 'TARGETS' 
2012-08-12 18:36:57,455 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>) target=TARGETS, selection=CLIPBOARD 
2012-08-12 18:36:57,455 do_selection_get(<GtkSelectionData at 0x7fff10466f80>, 0, 541091) 
2012-08-12 18:36:57,455 get clipboard from remote handler id=0 
2012-08-12 18:36:57,467 process clipboard packet type=clipboard-contents 
2012-08-12 18:36:57,467 process clipboard contents, selection=CLIPBOARD, type=ATOM, format=32 
2012-08-12 18:36:57,467 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9) 
2012-08-12 18:36:57,468 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)=[161L, 71L, 31L, 162L, 163L, 135L, 134L, 132L, 136L]=['\xa1', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\xa2', '\x00', '\x00', '\x00', '\xa3', '\x00', '\x00', '\x00', '\x87', '\x00', '\x00', '\x00', '\x86', '\x00', '\x00', '\x00', '\x84', '\x00', '\x00', '\x00', '\x88', '\x00', '\x00', '\x00'] 
2012-08-12 18:36:57,468 clipboard wire -> raw: ('ATOM', 32, 'atoms', ('text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS')) -> '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00' 
2012-08-12 18:36:57,468 got clipboard contents(0)=36 (type=ATOM, format=32) 
2012-08-12 18:36:57,468 get clipboard from remote result(0)={'data': '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00', 'type': 'ATOM', 'format': 32} 
2012-08-12 18:36:57,469 do_selection_get(<GtkSelectionData at 0x7fff10466f80>,0,541091) calling selection_data.set(ATOM, 32, <type 'str'>:36) 
2012-08-12 18:36:57,494 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>) 
2012-08-12 18:36:57,494 target for CLIPBOARD: 'COMPOUND_TEXT' 
2012-08-12 18:36:57,495 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>) target=COMPOUND_TEXT, selection=CLIPBOARD 

## Client log (paste to remote app):

2012-08-12 18:36:57,545 process clipboard packet type=clipboard-request
2012-08-12 18:36:57,545 process clipboard request, request_id=0, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
2012-08-12 18:36:57,545 get_contents(TARGETS,<function got_contents at 0x358f500>)
2012-08-12 18:36:57,550 unpack(<gtk.Clipboard object at 0x2ed9730 (GtkClipboard at 0x301b340)>, <GtkSelectionData at 0x2cba1c0>, <type 'NoneType'>:0)
2012-08-12 18:36:57,550 unpack(..) type=ATOM, format=32, data=<type 'str'>:72
2012-08-12 18:36:57,551 got_contents(ATOM, 32, <type 'str'>:72) data=[143, 0, 0, 0, 0, 0, 0, 0, 71, 0, 0, 0, 0, 0, 0, 0, 31, 0, 0, 0, 0, 0, 0, 0, 144, 0, 0, 0, 0, 0, 0, 0, 121, 0, 0, 0, 0, 0, 0, 0, 138, 0, 0, 0, 0, 0, 0, 0, 140, 0, 0, 0, 0, 0, 0, 0, 141, 0, 0, 0, 0, 0, 0, 0, 142, 0, 0, 0, 0, 0, 0, 0], str(data)=�G�y����
2012-08-12 18:36:57,551 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72:['\x8f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x90', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'y', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8a', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8c', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8d', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8e', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00']) using gdk atom code
2012-08-12 18:36:57,552 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atoms=[<GdkAtom 0x8f = 'text/plain'>, <GdkAtom 0x47 = 'UTF8_STRING'>, <GdkAtom 0x1f = 'STRING'>, <GdkAtom 0x90 = 'TEXT'>, <GdkAtom 0x79 = 'COMPOUND_TEXT'>, <GdkAtom 0x8a = 'TARGETS'>, <GdkAtom 0x8c = 'MULTIPLE'>, <GdkAtom 0x8d = 'TIMESTAMP'>, <GdkAtom 0x8e = 'SAVE_TARGETS'>]
2012-08-12 18:36:57,552 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atom_names=['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS']
2012-08-12 18:36:57,552 clipboard raw -> wire: ('ATOM', 32, '\x8f\x00\x00\x00\x00\x00\x00\x00G\x00\x00\x00\x00\x00\x00\x00\x1f\x00\x00\x00\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00\x00\x00y\x00\x00\x00\x00\x00\x00\x00\x8a\x00\x00\x00\x00\x00\x00\x00\x8c\x00\x00\x00\x00\x00\x00\x00\x8d\x00\x00\x00\x00\x00\x00\x00\x8e\x00\x00\x00\x00\x00\x00\x00') -> ('atoms', ['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS'])

comment:11 Changed 5 years ago by Antoine Martin

thanks.
this sample is from a qt app, right? do you get the same problem with an xterm?
had problems with qt before, see #84

it also looks like the atoms aren't being filtered, maybe because the target does not match? here - does it fix the problem if you force the atom filtering to apply?
you want to remove "COMPOUND_TEXT" and "SAVE_TARGETS".

they may have got removed accidentally by using the "wrong" code previously if those were ending up in the highest 32 bits.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 5 years ago by onlyjob

You're right, with unmodified 0.4.1 to my surprise pasting to 'xterm' worked but check 'kwrite' and I'm sure you'll see the problem...

So far I tried to remove the following from 0.4.1 (xpra/xposix/xclipboard.py) but it didn't help:

     atom_names.remove("SAVE_TARGETS")
     atom_names.remove("COMPOUND_TEXT")

Thanks.

comment:13 Changed 5 years ago by Antoine Martin

sorry, i meant the opposite: you want those two lines to fire everytime, even when the 'if' statement would not normally fire.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:14 Changed 5 years ago by onlyjob

Ops, sorry... Now I tried removing 'if' around 'atom_names.remove' but this alone didn't fix the problem in 0.4.1.

Thank you.

comment:15 Changed 5 years ago by Antoine Martin

Downloading 200MB of stuff just to get 'konsole' - sigh..

comment:16 Changed 5 years ago by onlyjob

Oh boy... :) Personally I'm addicted to Konsole. :)

Thank you for all your effort. You're doing a great work.

Much appreciated.

comment:17 Changed 5 years ago by Antoine Martin

OK, 200MB later and I finally got to see this "bug", which very much looks like another qt bug to me and explains why the previously broken code made it work with qt: it was discarding half the atoms (at random: whichever atoms ended up in the higher 32 bits) and ended up discarding the ones that qt does not like (more on that below).

So, r1315 adds the necessary code to make qt apps work again, but this is still commented out because I would much prefer finding a solution that does not also impair well behaved applications.
Until then, to make it work, just uncomment the "#discard_targets" line which is prefixed with "#for qt".
Works for me. Please confirm if this also works for you.

Why I think this is a qt bug: whenever we get a do_selection_request_event with one of the targets that qt apps barf on, we never get the corresponding do_selection_get, and the only thing in between those two calls is a plain gtk call to gtk.Invisible.do_selection_request_event. Not much else we can do here. It probably tries to do something very clever and fails miserably. During my testing I also saw some clipboard loops where the qt app repeatedly requests the same clipboard contents... sigh.

comment:18 Changed 5 years ago by Antoine Martin

Hang on a second... maybe I was completely wrong about this being a qt bug.

I am now totally confused about what the size of atoms should be when packed as structs (see for example r1317 - I tried using a '@Q' struct packing there, as the docs say I should? - but that failed)

Then I double-checked the size of GdkAtoms and since these are longs, changed the packing code to use native longs in r1318 and now qt apps seem to work without specific hacks.

I will definitely need to check all this again once I've had some proper sleep/rest (brain currently on strike), because it may just be that this change has the same effect as the previous "wrong" patch: discarding the atoms placed in the high 32-bits and therefore not really fixing the issue.

Testing/feedback welcome, especially with qt or Java apps - and apps that use more than just string clipboard (ie: utf8, etc)

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:19 Changed 5 years ago by onlyjob

Sure, I'll help with testing. (Though I won't be able to check Java app...)
This is a blocker for us as in Debian we can't ship package with known problem of copy/paste to of from QT apps...

Please take a good care of yourself and let us know when you ready. :)

By the way for debian packaging we have only two things left to do: fix this problem and introduce post-build testing #177 (minor).

Thank you.

comment:20 Changed 5 years ago by Antoine Martin

Unless someone can find an app that still exhibits clipboard problems, this ticket will be closed. I will also backport it to 0.3.x and 0.4.x later.

FYI: if Debian is not going to stick with the 0.3.x branch that I created specifically for it (sigh..), then it should go with 0.5.x instead, as it is in great shape now that this bug is fixed - the only thing holding up its release is the fact that I haven't got access to my VMs to test on and make builds for win32/OSX. (eta: end of the week) I have no intention of supporting end-of-line branches for much longer.
Also bear in mind that future releases will drop support for versions older than 0.5 (due to missing raw protocol features and new encoding formats)

comment:21 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

Backported to 0.4.x and 0.3.x branches in r1320

Feel free to re-open if you find a problem.

comment:22 Changed 5 years ago by onlyjob

Thank you, tomorrow I'll test and report.

Regarding Debian release, don't you worry - Wheezy will be released with 0.3.x.
We're in pre-release freeze now and at this time policy discourage new uploads without a very-very good reason.

Also we need to synchronise with transition of 'cython' - at this time its new version (required to build 0.4.x) is in 'experimental' only.

As you can see we have all the time we need to properly prepare new release. Recently I've made many packaging improvements and we will use all of those for 0.5 when you finish it. :)

I'm glad that's my packaging of 0.4.1 provided you with useful feedback.

Let's be in touch. Even if we make 0.4.x available from 'unstable' for some time you can be sure 0.5 will replace it soon enough.
You know, I'm an active user now. :)

I can't thank you enough for a fantastic technology that you've made available. I'm about 20 years in the industry and I'm convinced that xpra is the most superior remote access technology ever.

I'm indebted to you for your work.

Cheers,
Dmitry.

P.S. If you're going to release 0.5 in a matter of weeks 0.4 will not stand a chance to hit 'unstable'. :)

comment:23 Changed 5 years ago by Timo Juhani Lindfors

onlyjob, if you want to help with Debian work please subscribe to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680244 so that I get your name and email address :-)

comment:24 Changed 5 years ago by onlyjob

r1320 works well with 0.4.1
Thanks.

comment:25 Changed 5 years ago by onlyjob

Resolution: fixed
Status: closedreopened
Version: 0.4.0trunk

I tried latest trunk r1314 but the same problem is still there: it pastes nothing to remote application 'kwrite'.

## paste to remote app (server log):

2012-08-14 23:55:26,707 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>)
2012-08-14 23:55:26,708 target for CLIPBOARD: 'TARGETS'
2012-08-14 23:55:26,708 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>) target=TARGETS, selection=CLIPBOARD
2012-08-14 23:55:26,708 do_selection_get(<GtkSelectionData at 0x7fffb6e5e600>, 0, 134926973)
2012-08-14 23:55:26,708 get clipboard from remote handler id=1
2012-08-14 23:55:26,715 process clipboard packet type=clipboard-contents
2012-08-14 23:55:26,715 process clipboard contents, selection=CLIPBOARD, type=ATOM, format=32
2012-08-14 23:55:26,716 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)
2012-08-14 23:55:26,716 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)=[159L, 71L, 31L, 160L, 161L, 135L, 134L, 132L, 136L]=['\x9f', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\xa0', '\x00', '\x00', '\x00', '\xa1', '\x00', '\x00', '\x00', '\x87', '\x00', '\x00', '\x00', '\x86', '\x00', '\x00', '\x00', '\x84', '\x00', '\x00', '\x00', '\x88', '\x00', '\x00', '\x00']
2012-08-14 23:55:26,716 clipboard wire -> raw: ('ATOM', 32, 'atoms', ('text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS')) -> '\x9f\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa0\x00\x00\x00\xa1\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00'
2012-08-14 23:55:26,716 got clipboard contents(1)=36 (type=ATOM, format=32)
2012-08-14 23:55:26,717 get clipboard from remote result(1)={'data': '\x9f\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa0\x00\x00\x00\xa1\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00', 'type': 'ATOM', 'format': 32}
2012-08-14 23:55:26,717 do_selection_get(<GtkSelectionData at 0x7fffb6e5e600>,0,134926973) calling selection_data.set(ATOM, 32, <type 'str'>:36)
2012-08-14 23:55:26,746 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>)
2012-08-14 23:55:26,746 target for CLIPBOARD: 'COMPOUND_TEXT'
2012-08-14 23:55:26,747 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>) target=COMPOUND_TEXT, selection=CLIPBOARD

paste to remote app (client log):

2012-08-14 23:55:26,710 process clipboard packet type=clipboard-request
2012-08-14 23:55:26,710 process clipboard request, request_id=1, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
2012-08-14 23:55:26,710 get_contents(TARGETS,<function got_contents at 0x7f7d0802a488>)
2012-08-14 23:55:26,711 unpack(<gtk.Clipboard object at 0x1de76e0 (GtkClipboard at 0x1ed6b90)>, <GtkSelectionData at 0x1bc0200>, <type 'NoneType'>:0)
2012-08-14 23:55:26,712 unpack(..) type=ATOM, format=32, data=<type 'str'>:72
2012-08-14 23:55:26,712 got_contents(ATOM, 32, <type 'str'>:72) data=[142, 0, 0, 0, 0, 0, 0, 0, 71, 0, 0, 0, 0, 0, 0, 0, 31, 0, 0, 0, 0, 0, 0, 0, 143, 0, 0, 0, 0, 0, 0, 0, 120, 0, 0, 0, 0, 0, 0, 0, 137, 0, 0, 0, 0, 0, 0, 0, 139, 0, 0, 0, 0, 0, 0, 0, 140, 0, 0, 0, 0, 0, 0, 0, 141, 0, 0, 0, 0, 0, 0, 0], str(data)=�G�x����
2012-08-14 23:55:26,713 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72:['\x8e', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'x', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x89', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8b', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8c', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8d', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00']) using gdk atom code
2012-08-14 23:55:26,713 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atoms=[<GdkAtom 0x8e = 'text/plain'>, <GdkAtom 0x47 = 'UTF8_STRING'>, <GdkAtom 0x1f = 'STRING'>, <GdkAtom 0x8f = 'TEXT'>, <GdkAtom 0x78 = 'COMPOUND_TEXT'>, <GdkAtom 0x89 = 'TARGETS'>, <GdkAtom 0x8b = 'MULTIPLE'>, <GdkAtom 0x8c = 'TIMESTAMP'>, <GdkAtom 0x8d = 'SAVE_TARGETS'>]
2012-08-14 23:55:26,713 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atom_names=['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS']
2012-08-14 23:55:26,714 clipboard raw -> wire: ('ATOM', 32, '\x8e\x00\x00\x00\x00\x00\x00\x00G\x00\x00\x00\x00\x00\x00\x00\x1f\x00\x00\x00\x00\x00\x00\x00\x8f\x00\x00\x00\x00\x00\x00\x00x\x00\x00\x00\x00\x00\x00\x00\x89\x00\x00\x00\x00\x00\x00\x00\x8b\x00\x00\x00\x00\x00\x00\x00\x8c\x00\x00\x00\x00\x00\x00\x00\x8d\x00\x00\x00\x00\x00\x00\x00') -> ('atoms', ['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS'])

Interestingly if server is latest (fixed) 0.4.1 pasting from client trunk works.

Cheers,
Dmitry.

comment:26 Changed 5 years ago by Antoine Martin

r1314 is not the latest:

  • the fixes are in trunk as of r1318
  • in 0.3.x and 0.4.x branches as of r1320

Please re-test and close ticket if needed.

comment:27 Changed 5 years ago by onlyjob

Resolution: fixed
Status: reopenedclosed

My bad I missed few commits - it is working perfectly in trunk r1320.

Please ignore the noise. Sorry...

Last edited 5 years ago by onlyjob (previous) (diff)
Note: See TracTickets for help on using tickets.