www.cendio.com
Bug 5772 - server clipboard needs external process (vncconfig) to function
: server clipboard needs external process (vncconfig) to function
Status: CLOSED FIXED
: ThinLinc
VNC
: trunk
: PC Unknown
: P2 Normal
: 4.7.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2016-01-18 12:02 by
Modified: 2016-12-05 15:01 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2016-01-18 12:02:16
The clipboard in Xvnc does not work without vncconfig running. It was probably
done this way because it was the most obvious way to do it, given how X11
clipboard works. But that doesn't mean it's a simpler way of doing, as evident
by the fact that there are still magical hooks in Xvnc to help vncconfig, and
there is a new "VNC" extension to X11 to handle the clipboard data transfer.

It would probably be better if the clipboard was handled entirely inside Xvnc.
It will still be a moderately complex system though as the X server has poor
support for handling windows that are created internally. But it should at
least all the code can then be in one place, and it should be more robust as
there is just a single process handling things.
------- Comment #1 From cendio 2016-01-18 12:09:13 -------
An attempt at this here:

https://github.com/CendioOssman/tigervnc/tree/clipboard
------- Comment #4 From cendio 2016-07-12 13:32:57 -------
All done.

Tester should verify that the clipboard transfer works well in both directions
with various clipboard implementations. I.e. should try a GTK+ application, Qt
application, Java application, etc.
------- Comment #5 From cendio 2016-08-09 16:50:54 -------
Test protocol:

- Control of clipboard
  - Disable using SendCutText and AcceptCutText arguments to Xvnc
  - Changing above properties with vncconfig
  - Disable change of above properties from vncconfig (Xvnc argument
-noclipboard)

- Control of max clipboard buffer size

- Normal use of primary and clipboard with different toolkits
------- Comment #6 From cendio 2016-08-09 16:59:48 -------
Teseted using ThinLinc server and client build 5200, also tested new client
against old server.

> - Control of clipboard
>   - Disable using SendCutText and AcceptCutText arguments to Xvnc

Works as expected, tested defaults values, and manual enable/disable

>   - Changing above properties with vncconfig

Works as expected, changed the settings live using vncconfig from within a
session.

>   - Disable change of above properties from vncconfig (Xvnc argument
> -noclipboard)
> 

Adding -noclipboard to Xvnc arguments, vncconfig fails to change the properties
as expected.

> - Control of max clipboard buffer size
> 

Work as described. However only affects the size while copying into a vnc
session and not out from the session.

> - Normal use of primary and clipboard with different toolkits

Tested clipboard transfers from within a session to desktop and vice versa,
using application gedit (GTK), kate (QT), jedit (JAVA). Works as expected
except for strange inconsitency while using gtk application server side [1].


[1] While using gedit in a session and copies cyrillic text (russian) and then
pastes ib the desktop,  the string is escaped \n044b\n.... but when copying
from gedit on desktop side and paste into server, ???? is shown instead of
escaped chars. Also when using non GTK application server side, all pastes are
not escaped and ??? is shown.
------- Comment #7 From cendio 2016-08-18 15:31:23 -------
(In reply to comment #6)
> 
> [1] While using gedit in a session and copies cyrillic text (russian) and then
> pastes ib the desktop,  the string is escaped \n044b\n.... but when copying
> from gedit on desktop side and paste into server, ???? is shown instead of
> escaped chars. Also when using non GTK application server side, all pastes are
> not escaped and ??? is shown.

This depends on who does the conversion. VNC only handles latin-1, so we prefer
that if possible. GTK will often convert for us using the \uxxxx notation.
Other programs might not though, in which case we ask for UTF-8 data and do the
conversion ourselves. We have a very simple implementation right now that just
replaces unsupported characters with '?'.

It's further complicated by the fact that we use FLTK for clipboard and
conversion on the client, which might behave differently from our
implementation in Xvnc. Some convergence of this is done in the prototype for
bug 3895, but if we fix that bug then we'll have proper unicode support anyway.
------- Comment #8 From cendio 2016-08-19 09:54:45 -------
Work as expected, closing.