Refactor TurboVNC Viewer as a native application

[dcommander]

Mostly for historical reasons, the TurboVNC Viewer uses Java as a GUI toolkit. In the early 2010s, the Java TurboVNC Viewer received a great deal of funding from companies that were interested in deploying it as a web applet or a Java Web Start app. Thus, the Java TurboVNC Viewer evolved to the point at which it encompassed all of the critical features and performance of the native TurboVNC Viewer code bases, and it made sense to phase out the native code bases in favor of the Java TurboVNC Viewer with a built-in JRE. Since applets and Java Web Start are not supported anymore ¹, there is no technical reason why the TurboVNC Viewer couldn't be refactored as a native application. However, it would take a lot of labor. In addition to porting the TurboVNC Viewer base classes to C++ (or possibly reusing the TigerVNC Viewer base classes) and rewriting the GUI code, it would be necessary to refactor the TurboVNC Viewer’s built-in SSH client so that it uses libssh rather than a heavily modified version of JSch. I would probably want to use GTK as the GUI toolkit, due to its ubiquity and relatively small footprint, even though its API leaves much to be desired.

The current TurboVNC Viewer is deployed as a standalone application with a built-in JRE, as opposed to requiring a separate JRE, and it uses JNI for performance-critical subroutines (such as JPEG decompression) and O/S-specific workarounds for Java issues or limitations. Thus, refactoring it as a native application wouldn't really improve performance or usability. It would mainly improve maintainability, as well as facilitate supporting Wayland clients. (Java/Wayland is very much a work in progress, whereas popular C and C++ GUI toolkits have solid Wayland support these days.)

Footnotes

1. Technically, JWS is still supported via IcedTea-Web by Adoptium and Azul. However, this requires installing and managing an IcedTea-Web application on all clients, which is of debatable usefulness relative to installing and managing a TurboVNC Viewer application on all clients. ↩

[dcommander]

This is interesting: https://community.thinlinc.com/t/behind-the-scenes-qt-as-the-new-framework-for-thinlinc-client/1101. Not sure if they are planning to do the same for TigerVNC or if this will only be a ThinLinc proprietary thing. (Since ThinLinc is built around GPL-licensed code, it has never been clear to me how they can get away with adding closed-source features like audio and session management and such without integrating them into TigerVNC. I give them the benefit of the doubt by assuming that they wrap TigerVNC at the process level in order to implement the proprietary add-ons, but obviously that couldn't work with a new GUI framework.)

tl;dr: If the TigerVNC Viewer adopts Qt, then rebasing on the TigerVNC Viewer code would be a faster path to achieving the goal of a native TurboVNC Viewer. It would still be an expensive project, just not as expensive.