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.
An attempt at this here: https://github.com/CendioOssman/tigervnc/tree/clipboard
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.
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
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.
(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.
Work as expected, closing.
