On 10/20/15 1:41 AM, Brett Williams wrote:
> First, cut and paste does not consistently work (at least on the mac).
> Much of the time it works as expected, and then sometimes it doesn't
> work at all.  I use various workarounds (formatted text doesn't seem to
> work at all when copied on the mac and trying to paste into the VNC
> session).  Sometimes I'm left with no alternative but to use an OSX
> terminal, ssh in, and cut and paste there.  I work with long file paths
> and long filenames so typing them is inconvenient.  I may not have this
> set up correctly as I am running a separate vncconfig.  There are a lot
> of possible ways to attempt this and I haven't tried anything different
> when using the TurboVNC server.  This is definitely the most noticeable
> impact to my productivity.

I integrated the clipboard format patch from TigerVNC (disabling UTF-8 
transfers, which are in violation of the RFB spec), so I'm hoping that 
will address the issue you observed with formatted text, but since I 
have never personally observed that issue, it's hard to say.

I investigated the other clipboard patches from the TigerVNC Java 
viewer, but I ultimately could not find any test case in which those 
patches improved the errors that they were purported to fix, and the 
reworked clipboard handler in the latest & greatest TigerVNC code 
regressed behavior in other ways (didn't transfer all of the data.) 
OutOfMemory errors will tend to occur in the JVM when transferring large 
amounts of clipboard data from the Java viewer, and in my observation, 
using Java 8 on Mac fixed that, but on other platforms, the errors still 
occur.  I ultimately did integrate the feature from TigerVNC that allows 
limiting the max. clipboard size in the Java viewer.

A note about max. clipboard size:
TurboVNC 1.2.1 and prior would disconnect the viewer if a large 
clipboard update (> 1 MB) was received.  TurboVNC 1.2.2 - 2.0 will 
simply ignore the large update and print a message in the server log. 
The latest TurboVNC code (which will soon become 2.0.1 and 2.1 beta) now 
truncates large clipboard updates instead of ignoring them, thanks to a 
patch I just pushed to GitHub.  And the new MaxClipboard parameter in 
the Java viewer will also truncate large clipboard updates on the viewer 
end, to prevent sending data that the server will ultimately not use.

I also did observe on several occasions that clipboard transfers would 
temporarily stop working.  On OS X, I observed on a few occasions that 
the large clipboard transfer would silently fail with no error messages 
on either client or server.  On Windows, the large clipboard transfers 
failed more frequently and resulted in the following error in the Java 
viewer:

DesktopWindow: Error getting clipboard data:
DesktopWindow:   system clipboard data unavailable

I never saw any errors from tvncconfig.

At the moment, there isn't much else I can do about this unless I can 
get some reproducible test cases, but I'm hoping that the above fixes 
will at least improve the situation.  I haven't spun a build with these 
fixes yet.


> Second, the way scrollbars are implemented is not ideal, with an
> unnecessary vertical scrollbar.  At work, I have what amounts to a
> 3840x1080 display.  At home, I have 1920x1200.  So scroll bars appear
> when I'm at home because I can only see half of the X width.
> Unfortunately, vertical scroll bars are put on.  This means I can't see
> the full vertical space, even though I actually have 120 more pixels of
> monitor at home (it's left blank and grey in full screen mode).

So the issue here is that the Java viewer has to rely upon Swing to 
determine whether or not to add scrollbars, and it's difficult at best 
to determine whether that will happen before the window is actually 
resized.  There also doesn't seem to be a reliable way of determining 
what size those scrollbars will actually be, so there is no way to 
accurately predict whether the presence of one scrollbar (horizontal or 
vertical) will constrain the window real estate such that it forces the 
other scrollbar to appear.  Given how long it took for me to get the 
window resizing logic to work right while implementing the automatic 
desktop resize feature, I would really prefer not to mess with it.

My suggestion for the moment is to either use the automatic desktop 
resizing feature in TurboVNC or to simply maximize the window after you 
connect, which will eliminate the vertical scrollbar.

------------------------------------------------------------------------------
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users

Reply via email to