This is xpra 0.16 on GNU/Linux, with only local instances of xpra so far, using --mmap-group to share session between users.
The tray icon offers some clipboard choices: disabled, clipboard, primary, secondary. When having started the session with --clipboard=yes, none of these is selected and I can copy and paste with Ctrl+c/v and the middle mouse button as usual between host and xpra session.
The first issue is with the GUI: Once I had chosen primary, I can switch to clipboard, but there is nothing to select to get all of them again.
The second issue: Once I have chosen disabled, there is no clipboard action at all anymore, even after selecting some other entry from the menu. I see this in the terminal:
2016-04-15 16:48:41,343 Attached to :201 (press Control-C to detach) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 512, in remote_clipboard_changed self.client.setup_clipboard_helper(TranslatedClipboardProtocolHelper) File "/usr/lib/python2.7/site-packages/xpra/client/gtk2/client.py", line 286, in setup_clipboard_helper return helperClass(clipboard_send, clipboard_progress, *args, **kwargs) File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 36, in __init__ self.local_clipboard = getselection("local") File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 31, in getselection assert selections, "no %s clipboards!" % name AssertionError: no local clipboards! Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 512, in remote_clipboard_changed self.client.setup_clipboard_helper(TranslatedClipboardProtocolHelper) File "/usr/lib/python2.7/site-packages/xpra/client/gtk2/client.py", line 286, in setup_clipboard_helper return helperClass(clipboard_send, clipboard_progress, *args, **kwargs) File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 36, in __init__ self.local_clipboard = getselection("local") File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 31, in getselection assert selections, "no %s clipboards!" % name AssertionError: no local clipboards! Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 512, in remote_clipboard_changed self.client.setup_clipboard_helper(TranslatedClipboardProtocolHelper) File "/usr/lib/python2.7/site-packages/xpra/client/gtk2/client.py", line 286, in setup_clipboard_helper return helperClass(clipboard_send, clipboard_progress, *args, **kwargs) File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 36, in __init__ self.local_clipboard = getselection("local") File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 31, in getselection assert selections, "no %s clipboards!" % name AssertionError: no local clipboards!
My python is version 2.7.11 and there are fairly recent versions of other system stuff. I hope this is not too hard to fix. With this switch of clipboard on the fly, xpra is really useful as a application separation method with the optional exchange of information only after I allowed it. Ideally, I would start it with --clipboard=no and enable it once I want to copy something over. Normally, I do not want the possibility of xpra-contained applications sniffing other things in the primary selection (p.ex. passwords).
Please specify your client OS. I assume this is MS Windows?
(Hm, so Trac does not add comments based on mails … so I needed some time to grab that password remotely.)
So to the question of client OS: No, not MS Windows. I also see now that there is an Android component selected. That is also wrong, I guess it's a client issue. This is on a GNU/Linux x86-64 machine, working with xpra locally only, client and server (however you define that with X11;-).
Ah, Linux should not be using this menu at all - it doesn't make any sense there: the menu is only useful for platforms that have a single clipboard to sync with (win32 and osx), as it allows us to select which one.
r12402 + r12416 fixes that - a bit ugly. (r12408 for v0.16.x) Found some other things that needed fixing or improving along the way: r12403, r12404, r12405, r12406
Hopefully, we can clean this up some more in the next release as part of #276.
@beelzebug: does this work for you? (in trunk now)
Yes, this only shows a single toggle for clipboard now (r12408 on top of 0.16.3).
Now … if this would work to enable the clipboard again, too, I would be happy. Is that supposed to work? So far, I can only one-time disable the clipboard wholesale. My security considerations would be fully fulfilled if I had that on/off switch, with the added twist that switching it back on only synchronises new selections/clipboard copies (Ctrl+C), not existing ones.
How far off is that? But, well, it might be another ticket, as the confusing tray menu is gone, although it still confuses that I cannot reactivate the clipboard.
It kinda worked when you re-enable it, but not in all cases..
Lots of fixes now in trunk:
The non-debug changesets should be backported, but this needs testing first to ensure I haven't broken anything else.. @beelzebug: does this work for you?
Not heard back for 3 months, assuming this is fixed. Backport was in r12506.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1167