You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using Tcl/Tk offers a lot of advantages for this project. But unfortunately it also has some negative aspects:
The environment is not very well supported. There aren't any good IDE's for Tcl development available, which makes contributions quite difficult.
Due to the lack of native implementations we have to rely on external applications (OpenSSH, VNC servers), which are quite difficult to handle (especially in case of errors).
It is not possible to sign the created binary on modern macOS systems. Therefore it's basically impossible to start the application bundle on macOS in a straightforward way (without bypassing the security mechanics of the operating system).
On different platforms we use different VNC servers. Their feature set is quite different. Therefore it's not easily possible to provide a wider range of features on all platforms (e.g. file transfers).
Our goal is to provide a solution, that works reliably on all operating systems with a common set of features. After some investigation we came to the conclusion, that Java with its multi platform approach might solve these issues quite well - especially since they provide a way to create a stripped down version of their runtime environment since Java 9 (via Jigsaw / jlink).
After some experiments we can confirm, that our tests with java.awt.Robot offered comparable performance to the established VNC solutions. But of course there should be space for optimization left. ;)
Bundling the application with OpenJDK 10 leads to an uncompressed application folder with about 50MB. A compressed download has a size of about 25MB - 30MB. This of course is a lot bigger then most other VNC solutions. But these are still acceptable values for our use case. Considering the advantages of a consistent environment for all supported platforms outweigh the bigger download sizes from our point of view.
To make a long story short: We're planning to rework RemoteSupportTool entirely in Java. As far as we know, there are some similar projects in the Java world. But either they are not completely open source or they are not actively maintained anymore. Hopefully we can fill that gap and provide a solution, that is also helpful for other users / companies.
The text was updated successfully, but these errors were encountered:
Using Tcl/Tk offers a lot of advantages for this project. But unfortunately it also has some negative aspects:
Our goal is to provide a solution, that works reliably on all operating systems with a common set of features. After some investigation we came to the conclusion, that Java with its multi platform approach might solve these issues quite well - especially since they provide a way to create a stripped down version of their runtime environment since Java 9 (via Jigsaw / jlink).
After some experiments we can confirm, that our tests with
java.awt.Robot
offered comparable performance to the established VNC solutions. But of course there should be space for optimization left. ;)Bundling the application with OpenJDK 10 leads to an uncompressed application folder with about 50MB. A compressed download has a size of about 25MB - 30MB. This of course is a lot bigger then most other VNC solutions. But these are still acceptable values for our use case. Considering the advantages of a consistent environment for all supported platforms outweigh the bigger download sizes from our point of view.
To make a long story short: We're planning to rework RemoteSupportTool entirely in Java. As far as we know, there are some similar projects in the Java world. But either they are not completely open source or they are not actively maintained anymore. Hopefully we can fill that gap and provide a solution, that is also helpful for other users / companies.
The text was updated successfully, but these errors were encountered: