We should be able to rip it out and just use plain X11 calls (see ICCCM section 2: Peer-to-Peer Communication by Means of Selections), hopefully GTK won't get too confused by this...
We can keep the existing code, at least client side, for the non-X11 platforms.
Another reason for doing this, just hit this today (not sure how):
RuntimeError: maximum recursion depth exceeded Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/clipboard/clipboard_base.py", line 167, in _get_clipboard_from_remote_handler Error in sys.excepthook: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/quit.py", line 67, in gtk_main_quit_on_fatal_exception print(traceback.print_exception(etype, val, tb)) File "/usr/lib64/python2.7/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/usr/lib64/python2.7/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/usr/lib64/python2.7/linecache.py", line 14, in getline lines = getlines(filename, module_globals) File "/usr/lib64/python2.7/linecache.py", line 40, in getlines return updatecache(filename, module_globals) RuntimeError: maximum recursion depth exceeded Original exception was: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/clipboard/clipboard_base.py", line 167, in _get_clipboard_from_remote_handler log("get clipboard from remote handler id=%s", request_id) RuntimeError: maximum recursion depth exceeded
Re-scheduling due to lack of time.
Another item worth considering during the re-write would be to make all clipboards "greedy" like the win32 and osx ones, or at least having the option of doing that.
#1018 is a duplicate of this ticket.
Likely to be quite hard.
See also: #1589 GTK3 clipboard support
Preparatory steps added in r22212.
We can't completely do without GTK because the hooks for X11 events are in the gtk main loop filter, and the events are dispatched as gobject signals. But at least it should be easier to move away from GTK at some point.
And we also need to use the xfixes API, because it's better. See also #1494
The toy clipboard class can now send a receive clipboard data.
XGetWindowPropertyneeds to handle large data (continue) - HARD!
do_owner_changed()should fire a new token every time? for greedy clients only?
emit_tokenneeds to get
TARGETSand the data before sending
TARGETas part of the property name and maybe we shouldn't: in some cases the property name ends up looking like this:
PRIMARY-text/plain;charset=utf-8- is this always going to be a valid property name? could this be abused?
It works surprisingly well and does not ever lock the main thread!
COMPOUND_TEXTand other targets: let clients specify blacklist?
XGetWindowProperty: maybe pass the maximum buffer size (and remove icon hack)
XGetWindowPropertyfixed (4MB limit for clipboard transfers)
win32 native clipboard work in progress
We do have to deal with the macos clipboard to be able to cleanup the codebase and remove the legacy gdk clipboard classes.
Caused a regression: #2280.
This will do for this ticket, will follow up in #273.
@encodedEntropy: this really needs testing, ideally before #1844 so if anything is broken then we will know if it's here or there.
Something's not right.
When copying an image from
eog on the server (testing for #1494):
do_owner_changed() _send_clipboard_token_handler(X11ClipboardProxy(CLIPBOARD), ()) requesting local XConvertSelection from 'Image Viewer' for 'TARGETS' into 'CLIPBOARD-TARGETS' client @25.162 got token, selection=CLIPBOARD, targets=None, target data=None, claim=True, can-receive=True _send_clipboard_token_handler(X11ClipboardProxy(CLIPBOARD), (('TIMESTAMP', 'TARGETS', 'MULTIPLE', 'image/png', 'image/bmp', 'image/x-bmp', 'image/x-MS-bmp', 'image/x-icon', 'image/x-ico', 'image/x
Why do we request the targets and send a clipboard-token to the client without them? Do one or the other!
Terminal are being greedy and requesting the targets:
client @25.164 clipboard request for CLIPBOARD from window 0x3400125: 'gedit' client @25.166 clipboard request for CLIPBOARD from window 0x2400002: 'Terminal'
We get the targets again:
proxy_got_contents(6, CLIPBOARD, TARGETS, ATOM, 32, <class 'bytes'>:192) data=0xa001...
And send them to the client:
client @25.167 got token, selection=CLIPBOARD, targets=(b'TIMESTAMP', b'TARGETS', b'MULTIPLE', b'image/png', b'image/bmp', b'image/x-bmp', b'image/x-MS-bmp', b'image/x-icon', b'image/x-ico', b'image/x-win-bitmap', b'image/vnd.microsoft.icon', b'application/ico', b'image/ico', b'image/icon', b'text/ico', b'image/jpeg', b'image/tiff', b'UTF8_STRING', b'COMPOUND_TEXT', b'TEXT', b'STRING', b'text/plain;charset=utf-8', b'text/plain', b'text/uri-list'), target data=None, claim=True, can-receive=True
We should filter the
image/FORMAT list to only contain formats that we can process through pillow.
We tell both
Terminal about the targets:
client @25.168 setting response b'\x99\x01\x00\x00.. ..\x00\x00' to property GDK_SELECTION of window 'gedit' as ATOM client @25.168 setting response b'\x99\x01\x00\x00.. ..\x00\x00' to property GDK_SELECTION of window 'Terminal' as ATOM
Probably because we claim the clipboard again when handling this token, they request the targets again, and we respond with the cached value:
client @25.171 clipboard request for CLIPBOARD from window 0x3400125: 'gedit' client @25.171 using existing TARGETS value as response client @25.172 clipboard request for CLIPBOARD from window 0x2400002: 'Terminal' client @25.172 using existing TARGETS value as response
When trying to paste it into the gimp, it requests the data in
client @19.259 clipboard request for CLIPBOARD from window 0x42029cd: 'GNU Image Manipulation Program' client @19.259 using existing TARGETS value as response client @19.264 clipboard request for CLIPBOARD from window 0x42029cd: 'GNU Image Manipulation Program' client @19.264 send_clipboard_request_handler(X11ClipboardProxy(CLIPBOARD), 'CLIPBOARD', 'image/png')
The server tries to honour it:
requesting local XConvertSelection from 'Image Viewer' for 'image/png' into 'CLIPBOARD-image/png' proxy_got_contents(1, CLIPBOARD, image/png, INCR, 32, <class 'bytes'>:8) data=0x470b040000000000..
xpra.x11.bindings.window_bindings.BadPropertyType: incomplete data: 196608 bytes after
Because we don't handle INCR properties.
added PoC overlay code in r22826 from both images and timestamp, only for png images for now.
Supporting this in the html5 client is going to be difficult, #1844 may help. See:
Moving html5 to #2312.
Unrestricted html5 clipboard access (at least for chrome): #2320.
See also brotli compression for text: #2289
Works well enough for this release. Closing.
Issues should be filed as new bugs, pointing back to this ticket.
See also updates in #1844.
Another regression spotted: ticket:2338#comment:3.
Clipboard won't work well at all with wayland clients, even if we re-added the GTK code (see ticket:2243#comment:10).
The nested-main-loop code is finally removed in r23470.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/812