it should be possible to go back to the default values (-1 and -1), so use None default values for max_send_size and max_receive_size in set_direction and check for None in set_limits - then you can just do xpra control :100 clipboard-limits -1 -1

have you tested the control command? unless I am missing something, without input validation the control values will be strings and then this breaks badly, in python2 the size check fails silently (removing the restrictions):

> 3 > "1"
False

with python3 you probably get an error in the clipboard code on every request (which may be worse as this is known to cause GTK to hang)

in control_command_clipboard_limits, you alias the clipboard helper to a local variable (good), but then you don't use it

the setting_changed method takes native values, not strings, either send a pair of values or a dictionary

Did you test this? Ideally this feature should be added to the unit tests.

I found at least two major problems during my quick testing:

r21202 fixes a long standing bug that is uncovered by the extra "truncated" attribute in the "clipboard-contents" packets - do you really need this? (it will create backwards compatibility issues with older versions - as some users just don't update as often as they should..)

the checks assume that a limit is always set:

2018-12-11 13:56:49,818 Data copied out truncated because of clipboard policy 1 to -1

r21202 fixes a long standing bug that is uncovered by the extra "truncated" >attribute in the "clipboard-contents" packets - do you really need this? (it will create backwards compatibility issues with older versions - as some users just don't update as often as they should..)

You are right. I am actually thinking to add a clipboard-content-truncated message instead of changing the clipboard-content packets. All I need is to notify the client in some way. What do you think?

I am actually thinking to add a clipboard-content-truncated message instead of changing the clipboard-content packets. All I need is to notify the client in some way. What do you think?

If you need to notify the client, then I would rather not add a new packet type.
We can workaround older clients by adding a new capability flag in the hello packet - something like clipboard-contents-slice-fix=true.

Fired up a trunk r21225 server, and followed the steps for using the control channel - primarily xpra control :DISPLAY clipboard-limits 8 8 and it broke the server side clipboard. I could copy text from my client into the server clipboard, but could not copy anything on the server. If I did, the clipboard would be empty, and I couldn't paste anything client side.

I ran a session with -d clipboard demonstrating what I saw. My repro steps are pretty easy:

Start a server with xfce4-terminal or some terminal emulator with a Copy/Paste? menu

Run xpra control :DISPLAY clipboard-limits 8 8

Copy some text from the client into the server

Type something into the terminal, highlight it, and try to paste it into a client application (I just used kwrite)

I tried that on three different sessions, and it failed each time. I'll work on using the Environment variables and using xclip.

When I copy from the client to server, I get as much text as I should within the limits - 8 characters. But when I highlight text on the server, copy it, and then paste it client-side, there's no data.

I just installed xclip, and I restarted my server and now it's working?