Our current Java viewer is based on the RealVNC code, not the TightVNC-based viewer. In fact, it still says "RealVNC" whenever you run it. :) It's on my long-term list of things to do to merge in a bunch of features from the TurboVNC Java viewer, but the problem is that TigerVNC's current Java viewer doesn't even support Tight encoding yet. I would need that in place before I could do any merging. We had a guy who was supposed to work on it, but I haven't heard from him recently.
At least in the TurboVNC community, the Java viewer is very popular, even to the point that I've been approached about developing a version that uses JNI and libjpeg-turbo to accelerate the JPEG encoding (thus making the Java viewer run as fast as the native one.) However, the interface of the TurboVNC Java viewer (which is based on the one from TightVNC) is quite clunky. The fact that yours looks like the Windows viewer intrigues me. If it supported Tight encoding, I would be in favor of you merging it into our trunk once you had it somewhat stabilized. I personally don't have a lot of free time to work on it without funding, but I could probably help you test it, at least. The sad state of our Java viewer and the fact that no one has complained about it somewhat reflects the fact that it isn't a big priority for the TigerVNC community. We really need some people who are both passionate and knowledgeable about Java to join the project. On 3/15/11 1:10 PM, Brian Hinz wrote: > Sorry to jump on this thread so late, but with regards to the java > viewer... I have a version that I've been developing for a customer for > about a year & half now. It's based on the RealVNC code rather than the > TightVNC, but it has a fair amount of features if anyone is interested. > The interface has been ported to swing and looks nearly identical to the > RealVNC windows exe. I've implemented 24-bit color depth, wheel mouse > support, full-screen mode, etc. I had implemented TLS + plain password > auth in the gtk-vino style, but I'm currently re-writing this to support > VeNCrypt instead (that work is partially complete, no x509 support > yet). The initial motivation for this work was the ability to deploy > and update it as a signed applet via JWS, which is still an advantage of > a java client. Obviously, another viewer is probably the last thing > anyone wants from a code management standpoint, but I do think it's > easier to keep the RealVNC-based java code in sync with the core C code > than the TightVNC-based java. Anyway, just thought that I'd toss it out > there... > > -brian > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > > > _______________________________________________ > Tigervnc-devel mailing list > Tigervnc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tigervnc-devel ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
