dcommander
commented
4 years ago Are you asking about porting the entire standalone TurboVNC Viewer to GTK or about embedding a TurboVNC client in your existing GTK application?
If you're interested in embedding a TurboVNC client in your application, then I would suggest looking at LibVNCClient. LibVNCServer/LibVNCClient doesn't contain the RFB flow control extensions or other protocol enhancements that the TurboVNC Viewer contains (I would be willing to port those into LibVNCServer/LibVNCClient on a contract basis), but it at least contains the TurboVNC decoder, so it should be able to approach the speed of the TurboVNC Viewer on high-speed networks.
If you're interested in porting the entire TurboVNC Viewer to GTK, I've had interest in that as well, but I could never get the necessary funding for such a project. The Java TurboVNC Viewer has become our focus primarily because that was where I received funding. That funding came from companies that were interested in an Android TurboVNC Viewer or in Java Web Start "back in the day" (neither is a priority now), but that funding helped the Java TurboVNC Viewer mature to the point at which we're deploying it as a standalone application with an embedded JRE in TurboVNC 3.0. Given that there are significant improvements to the TurboVNC Viewer in 3.0, including most notably the TurboVNC Session Manager (which would be difficult to port into a native viewer because of its use of an embedded SSH client), and given that the Java TurboVNC Viewer performs as well as a native viewer, a new TurboVNC Viewer based on GTK would have a steep road to climb in order to match the same functionality. If I were developing such a viewer, I would probably start with the final Java TurboVNC Viewer code base, once TurboVNC 3.0 is released, and port it back to C++-- possibly borrowing code from TigerVNC as necessary. Our own native TurboVNC Viewer code base, which is going away with TurboVNC 3.0, is based on the old TightVNC 1.3.x code base, so it isn't as cleanly laid out (primarily because it was designed around raw Win32 GUI code) and doesn't have the same functionality. Since the Java TurboVNC Viewer is becoming a standalone application, there is no real reason to use Java anymore. It's used solely for the historical reasons described above. Thus, if a GTK TurboVNC Viewer port could be introduced without a loss of functionality, I would be open to switching to that code base in a future major release of TurboVNC. Even with an outside code contribution, however, I would still need funding to clean up and test and release the new viewer code.
We want to port the turbovnc viewer to our product, any good suggestions?