The tab key is not sent to the customer application during a support session. Instead the staff application switches the focus to the next GUI component.

The "commons-io" library should be updated from version 2.6 to 2.8.0.

see https://commons.apache.org/proper/commons-io/changes-report.html

With the migration to Java (see #9) we're going to change the license from MIT to Apache 2.0. This should not make a huge difference for the users. But because all of our Java based projects are licensed with Apache 2.0, we like to have some sort of consistency here.

For a better integration in Gnome / Ubuntu Unity we should set the sun.awt.X11.XToolkit.awtAppClassName class variable for the applications. Unfortunately this requires an ugly hack, because this variable declared private. Hopefully the OpenJDK guys will find a solution for this in the future.

Certain settings for performance / quality might be editable during a support session:

• level of JPEG compression (currently 60% by default)
• screenshot interval (currently 250 ms by default)
• width / height of transferred screenshot tiles (currently 100 px by default)

As an alternative to the signed application bundle, we can also provide a shell script for macOS systems, that extracts and launches the application (via Makeself) - similar to the provided Linux scripts.

The macOS operating system currently executes shell scripts without being signed by Apple. No paid developer account is required in this case.

Also a shell script can easily be downloaded and started with a one liner on the terminal:

curl -o support.sh https://mywebsite.com/CustomerSupportTool.sh && sh support.sh && rm -f support.sh

If multiple monitors are used on Linux systems, the customer tool shows wrong screen information in the screen selection field. The resolution of monitor A is shown, if monitor B is selected. The user might select the wrong screen because of the wrong / misleading information.

I'm not sure, if this happens in any case and for all operating systems - but GraphicsDevice#getDisplayMode() undoubtably returns wrong values in certain situations. Therefore we're not calling this method in the future and extract screen information via GraphicsDevice#getDefaultConfiguration() instead, which returns the expected values.

I am not sure how to debug this. I have some experience with C#, but none with TCL. The window location is off the screen on my multi monitor setup when I launch the application. I am not sure where to even begin making those modifications since for the most part the TCL seems to be a bundling script as opposed to a full programing language

First of all thank for your awesome project, my issue is how add more host and port fields and the possibility to substitute iP by a number or name.

If the customer (server) uses multiple monitors, he can select which monitor to share before the support session is started. Currently this cannot be changed after the support session was started.

It would be a nice addition, if the customer (server) or support staff (client) would be able to switch to another monitor while the support session is running.

Sometimes the costumers screen resolution is bigger than that of the staff.
In this case the screen is resized to fit the staff resolution at the moment.
It would be nice if there would be an on/off 1:1 option in the staff window during a remote session to switch to costumer resolution and to add scroll bars in the staff window to enable navigation.

The Java Runtime Environment (OpenJDK), that is bundled with the application, should be updated to the latest version 11.0.10+9.

It would be great to have an optional reconnect feature.
I have customers who starts the connections once and leave the window open for me to work for a longer period alone. If the connection is dropped because of some network glitch, the customer has to manually reconnect at the moment. This takes time and causes work interruptions. It would be great to have on option "Automatic reconnect" in the client GUI. The client watches if the connection is down, and it reconnects automatically to the Staff Tool when the checkbox is checked and of course the client GUI is still running.

The application on top of the about text is currently always in English language. We should use the translated application title instead.

Up to now we only provide a graphical interface for the user, that likes to share his desktop. Reworking the application with Java 10 (see #9) also allows us to create a graphical interface for the support staff. This makes it a lot easier for the support side to open a support session. No external requirements (separate VNC viewer, manual SSH tunneling, etc.) are needed.

In order to make downloaded application bundles usable on latest versions of macOS, they need to be notarized by Apple. See also Notarizing macOS Software Before Distribution.

Hi, I am Korean and My English is not good.
Recently I take this program and compile with Ubuntu by myself with downloading master.zip file.
Compile is fine,
but when I click 32bit-exe file in the launch4j folder, it has an error [ This application requires a Java Runtime ENvironment 10(32bit)]
With [https://github.com/OpenIndex/RemoteSupportTool/releases] 's StaffSupportTool-1.0.0-win32.exe & CustomerSupportTool-1.0.0-win32.exe, it is working with my Win 10 64 bit PC.
When i search Java 10 32bit , it is not exist.
How can i solve it?
Thank have good day.

OpenSSH doesn't start when I try to connect from a Windows 10 Machine via the GUI, but it is working if I start it from CMD without the -f parameter (and without sleep 15). Does somebody know what to do, to make it working? From Linux its just working fine.

The "jna" libraries should be updated from version 5.2.0 to 5.7.0.

see https://github.com/java-native-access/jna/blob/master/CHANGES.md

The mouse pointer of staff and customer are at a different positions.

It is only correct a the top left corner.
I guess this is caused by the highdpi screen at customer side (windows 10 with scaling > 200%). RemoteSupportTool uses a low res screenshot, but it doesn't scale the mouse position of staff from low res to high res. To fix use native res screenhot or scale the mouse position.

Clipboard sharing between the support staff and customer would be nice and helpful addition.

The provided x11vnc binary does not work on amd64 Linux systems, when libxss is not installed. Therefore we're going to provide a custom build of x11vnc, that does not require this library to be available.

Processing keyboard inputs in the customer application during a support session is kind of tricky. Simple ASCII characters can be printed without problems - but language and platform specific characters (e.g. German umlauts or backslash on Windows) are difficult to handle - especially if staff and customers use different operating systems with different keyboard layouts.

In version 1.0.0 we've misused the system clipboard in order to transfer unicode characters (as described here). On Windows customers we also used a workaround based on the numeric keypad.

The clipboard workaround leads to certain problems - especially for Linux and macOS customers (where the numeric keypad workaround doesn't work). If the currently focused application doesn't support the CTRL+V (or META+V) keyboard shortcut, the text is not properly inserted. Much worse, if the focused application implements other behavior on this keyboard shortcut, it might not be possible to use the focused application at all. The macOS terminal application and most Linux console applications are not working as expected because of this.

Therefore we've decided to rework keyboard inputs completely. Instead of typing characters with the Robot API we're directly calling the native API of the customers operating system via JNA.

• XTEST Extension Library on Linux
• Quartz Event Services on macOS
• SendInput on Windows

If these API calls fail, the application will fallback to a less compatible solution (numeric keypad on Windows or the Robot API). This makes the application still usable but some special / unicode characters may not be transferred properly. Using the "copy to clipboard" feature from the staff application might circumvent those problems.

The Customer Tool uses sidebar_staff.png as a sidebar image. The file name is misleading as it is not used in the staff tool. Therefore the file should be renamed to sidebar.png. For backwards compatibility sidebar_staff.png should still be used, if sidebar.png is not present.

The "SLF4J" library should be updated from version 1.7.26 to 1.7.30.

see http://www.slf4j.org/news.html

Due to a bug in Java 11.0.2 we had to disable encryption via TLS 1.3, which was introduced with Java 11. The problem was fixed in Java 11.0.3. Therefore we can re-enable TLS 1.3 as soon as the new Java version is integrated into the application.

Some customers have proxy servers. Would be nice if the client would provide proxy settings and could connect through it.

error while compile
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3. 8.0:compile (default-compile) on project RemoteSupportTool-Core: Fatal error com

Unfortunately our current PyInstaller based build system has some downsides. After spending a lot of time and frustration we were still not able to produce application binaries anymore on certain systems. Due to our limited time and lack of knowledge about the internals of PyInstaller we were not able to track down the cause of the problem.

Therefore we've decided to migrate the application from Python to Tcl/Tk. This allows us to implement an easier and more flexible build system. Based on precompiled tclkit binaries it is possible to cross compile the application for all supported target systems on a single machine without any hassle.

Besides the application itself all build scripts were ported from Bash & Batch to Tcl/Tk. This means, that we don't need to provide separate build scripts for Windows anymore. The build scripts can be used on every operating system with an installed Tcl environment. If that is not possible, one might also use one of the provided tclkit binaries in order to execute the build scripts.

Unfortunately there is no comparable alternative to Paramiko available for Tcl. Therefore we're using OpenSSH for SSH tunneling. Linux and Mac OS X are providing OpenSSH out of the box. For Windows systems we've integrated the binaries provided by mls-software.com.

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.

Hello sir

Can you tell me is this Software works for more than 1 client and support staff or 1 to many or many to 1 .Can you tell me please

The urls to AdoptOpenJDK in the openjdk init scripts did not work. Please find the working ones in the diff.
A nice enhancement would be if the init scripts would check the exit value of curl for easy and obvious detection of changing urls in the future.

diff --git a/release/share/openjdk/init-linux64.sh b/release/share/openjdk/init-linux64.sh
index ea7ca59..c06bbdb 100755
--- a/release/share/openjdk/init-linux64.sh
+++ b/release/share/openjdk/init-linux64.sh
@@ -25,7 +25,8 @@

-----------------------------------------------------------------------

TARGET="linux64"
-TARGET_JDK="https://github.com/AdoptOpenJDK/openjdk10-releases/releases/download/jdk-10.0.2%2B13/OpenJDK10_x64_Linux_jdk-10.0.2.13.tar.gz"
+TARGET_JDK="https://github.com/AdoptOpenJDK/openjdk10-releases/releases/download/jdk-10.0.2%2B13/OpenJDK10_x64_Linux_jdk-10.0.2+13.tar.gz"

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
DOWNLOADS_DIR="$DIR/downloads"
diff --git a/release/share/openjdk/init-windows64.sh b/release/share/openjdk/init-windows64.sh
index 95bc9fb..89dd620 100755
--- a/release/share/openjdk/init-windows64.sh
+++ b/release/share/openjdk/init-windows64.sh
@@ -25,7 +25,8 @@

-----------------------------------------------------------------------

TARGET="windows64"
-TARGET_JDK="https://github.com/AdoptOpenJDK/openjdk10-releases/releases/download/jdk-10.0.2%2B13/OpenJDK10_x64_Windows_jdk-10.0.2.13.zip"
+TARGET_JDK="https://github.com/AdoptOpenJDK/openjdk10-releases/releases/download/jdk-10.0.2%2B13/OpenJDK10_x64_Win_jdk-10.0.2+13.zip"

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
DOWNLOADS_DIR="$DIR/downloads"
diff --git a/release/share/openjdk/init.sh b/release/share/openjdk/init.sh
index f3a8c75..c1a47e1 100755
--- a/release/share/openjdk/init.sh
+++ b/release/share/openjdk/init.sh
@@ -39,7 +39,7 @@ case "$SYSTEM" in
case "$SYSTEM_ARCH" in
x86_64)
echo "Initializing Linux 64bit environment..."

•      SYSTEM_JDK="https://github.com/AdoptOpenJDK/openjdk10-releases/releases/download/jdk-10.0.2%2B13/OpenJDK10_x64_Linux_jdk-10.0.2.13.tar.gz"
  

•      SYSTEM_JDK="https://github.com/AdoptOpenJDK/openjdk10-releases/releases/download/jdk-10.0.2%2B13/OpenJDK10_x64_Linux_jdk-10.0.2+13.tar.gz"
       ;;
     i686)
  

File sharing between the support staff and customer would be nice and helpful addition.

Due to some changes in macOS Big Sur regarding security, we've decided to replace the current Bash script in our application bundles with a new native launcher. The native launcher is provided as a separate Open Source project called JavaMacLauncher and can be found at https://github.com/OpenIndex/JavaMacLauncher. Further information about the motivation are described at the project's description.

How can I send CTRL-ALT-DEL from the staff Application to the client application without the client OS intercepting it?
The client screen locked and I did not find a way to send the unlock keys.
I tried this [1], but it did not work.

[1] https://www.pointdev.com/en/faq/faq-ideal-administration-send-ctrl-alt-del-tightvnc-vnc-logon-sas-computer-machine-id-227.html

Hello sir c
can you provide binaries please .Bin Files are in German can u do it in English too please

The "commons-text" library should be updated from version 1.6 to 1.9.

see https://commons.apache.org/proper/commons-text/changes-report.html#a1.9.1

On some Linux distributions the applications look pretty ugly (depending on the desktop environment / default system look & feel). Therefore we're always enforcing the Nimbus look & feel on Linux systems. If this is not available, we should fall back to the Metal look & feel.

The position of the mouse cursor send by the staff is not properly shown on the customer's machine, if the customer uses multiple monitors.

We were able to reproduce this problem for Linux customers with a multi monitor setup provided by the Nvidia graphics driver. It's currently not clear, if the same problem occurs in other scenarios (Xinerama on Linux or generally on other operating systems). Further investigation is required.

During a support session the staff application should provide an option to enable / disable the transfer of keyboard & mouse inputs.

Very nice the new version Thank you !!!
In customer version if I try to open a program as administrador Staff side see a Black screen.

i want to run client and staff application on different different network for this purpose what changes i have to do .

The staff tool on macOS doesn't send characters to the customers, that are typed together with the option key (e.g. @ character via ⌥ + L or € character via ⌥ + E).

Java handles the option key a bit strange and returns true on KeyEvent#isAltDown() although it actually isn't the ALT key.

During a support session an uppercase character entered by the support staff is always printed as lowercase character at the customer's machine. This problem only occurs for customers with Linux systems.

It looks like the cause of the problems lies in the native calls on the X11 API, which were newly introduced with version 1.1.0.

It seems that the customer application is not properly working on Linux with Wayland. If the customer application is running on Fedora 29 (latest version), the staff only receives a black screenshot.

It might be an issue with OpenJDK. Or maybe there might be a way to explicitly allow an application to take screenshots. Fortunately Wayland is currently not widely used. But sooner or later we need to find a solution.

The "commons-lang" library should be updated from version 3.8.1 to 3.12.0.

see https://commons.apache.org/proper/commons-lang/changes-report.html

The bundled version of OSXvnc does not support Retina displays. Some forks at GitHub seem to fix that issue.

The following application properties should be integrated into Customer Tool:

• connectionSettingsVisible (true / false) to hide the connection settings from the customer on startup
• connectionSettingsEditable (true / false) to disallow changing the connection settings for the customer

In case of connectionSettingsVisible=false and connectionSettingsEditable=true a button should be available, that makes the hidden connection settings visible for the customer.