Glad you had a chance to look at it.  I've actually made a ton of fixes over
the last two weeks or so.  I found that there is some sort of bug in
IndexColorModel that causes the vncviewer fits with 8bpp color maps.  It
only occurs with JRE < 1.6.  Ultimately I just switched it to an 8bpp
DirectColorModel because I could find no other working solution.  It doesn't
look as nice, but for the sake of compatibility it was necessary.  I left
all the colormap code in, hopefully there's a fix that I just overlooked.  I
need to export all of those changes from our intranet repo at work and sync
them with my internet repository.  If there's enough interest, can we create
a branch in the tigervnc repo?

The GUI needs a couple of minor tweaks, and VeNCrypt configuration is
definitely one of them.  Another is the ability to specify a different
remote username than the local one (ours are always the same so this was
just laziness on my part).

I've actually been wondering about Hextile versus Tight.  I found some old
benchmarks, but has a rigorous comparison been done recently?  Under what
circumstances is one better than the other?  I'm sure it's the
implementation, but so far, all of my users agree that (at least with this
client) hextile seems to perform better than tight.  We're all on GbE fiber
so it's a little hard to quantify, the redraw time just seem a little
faster...

The other big item that you may have noticed is that I have a custom
security type in there that I would like to see supported in the community
version of the RFB protocol.  This security type (I called it "managed")
allows a daemon listening on port 5900 to respond to incoming requests by
either redirecting the client to connect to an already established server,
or spawn a new server and direct the client to that one.  The idea behind
this, as opposed to static servers defined in /etc/sysconfig/vncservers or
in /etc/xinetd.d/Xvnc, is that (1) users can manage their own preferences,
and (2) it eliminates the need to administer and maintain the port
assignments.  I have a rather basic daemon written in perl.  It needs some
work to make it shine (the ability to parse a real config file, etc.) but
for the purpose of demonstrating the usefulness of this security type it's
more than adequate.  I can document the exact protocol and formally request
this, as well as provide the sample daemon.

Thanks,
-brian

On Mon, Apr 18, 2011 at 3:17 PM, DRC <dcomman...@users.sourceforge.net>wrote:

> This is cool stuff.  From the point of view of integrating it into
> TigerVNC, I see only a few minor issues with its current behavior:
>
> -- It should honor the security type preference order from the server.
> Currently, it will enable TLS if the server advertises it, regardless of
> whether the server prefers something else.
>
> -- Really needs some sort of GUI for setting the VeNCrypt preferences.
>
> -- It needs to favor the Tight encoding type.  Currently, it seems to
> prefer Hextile.
>
> Otherwise, I don't see anything wrong with this.  Nice work!
>
>
> On 3/16/11 11:10 PM, Brian Hinz wrote:
> > Here's the source repo for the java viewer that I've been working on:
> >
> > https://bphinz.svn.cvsdude.com/vncviewer/
> > <https://bphinz.svn.cvsdude.com/vncviewer/trunk/java/>
> >
> > <https://bphinz.svn.cvsdude.com/vncviewer/trunk/java/>Have a look and
> > let me know what you think.  I'm going to start working on filling in
> > the gaps in the VeNCrypt security type from Martin's earlier work in the
> > next few days.
> >
> > -brian
> >
> > On Wed, Mar 16, 2011 at 9:18 AM, Brian Hinz  wrote:
> >
> >
> >
> >     On Wed, Mar 16, 2011 at 2:49 AM, Martin Koegler wrote:
> >
> >
> >         RealVNC Java 4.1 uses a simpliar class modes as the C++ version
> [I
> >         have VeNCrypt patches for such a viewer too].
> >
> >
> >     Thanks.  I will have a look at those patches tonight.
> >
> >         On the other hand, the TigerVNC java viewer is based on Tightvnc
> >         [some
> >         files are even carring such a copyright]. I had riped out some
> >         unsupported Tightvnc Code (Tight Security Type).  The sources
> >         contain
> >         a TightDecoder.java, so I doubt that it does not support Tight
> >         Encoding.
> >
> >
> >     I did look at the TightDecoder.java in the tigervnc source when I
> >     was adding tight encoding to my fork, but honestly I found it much
> >     easier to just put the C++ side-by-side with the RealVNC java code.
> >     I did not bother with the tight security type either.
> >
> >     -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
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Tigervnc-devel mailing list
> Tigervnc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

Reply via email to