This article introduces publishing single applications with ThinLinc, and discusses some of the benefits and limitations of doing so.
Introduction
Each ThinLinc session is built around a server-side process called Xvnc. Xvnc is the main process in any ThinLinc session, and is essentially an X server and VNC server combined. Applications publish their graphical output to Xvnc just as they would to a normal X server, but instead of ending up on a physical screen, it gets translated into the VNC protocol and sent across the network to the ThinLinc client.
For a ThinLinc remote desktop session, the first applications to send their output to Xvnc are typically components of a desktop environment (DE): the task bar, a desktop background, a window manager, and so on. ThinLinc is configured by default to detect any installed desktop environments and make them available to users, so the process of starting these components is automatic. Any application that the user starts from within this DE will also send its output to Xvnc, and therefore appear on the client machine:
Running a Single Application
The first application to be run inside a ThinLinc session does not necessarily have to be part of a desktop environment, however. Any X11 application can be run here instead, and the output will end up being displayed on the ThinLinc client. This can be useful in situations where the administrator doesn’t want users to have access to a full desktop environment, only a single application. Note that many user applications expect to be run within the context of a desktop environment, and can behave strangely otherwise. We can test this using the “Start the following application” functionality of the ThinLinc client to start a web browser:
Note how the browser interface is a fixed size, and cannot be moved. It is not possible to maximise or minimise the application, as these functions are handled by the window manager which was not started as part of the session, nor is there any taskbar or system tray to minimise the application to. Simple applications such as a terminal or text editor may be fine to run in this way, but others require additional desktop components in order to function properly. Without them, certain aspects of the application such as menus, pop-up windows, or notifications, may work poorly or not at all.
tl-single-app
To help with this, ThinLinc ships with a helper script called tl-single-app. This script takes an application as an argument, and launches it inside a lightweight window manager (Openbox) with a very basic configuration. The application will start maximised, with most window decorations and functionality disabled, inside a ThinLinc session with no desktop environment loaded.
The minimalist window decoration, and the fact that the application is maximised to take up the full ThinLinc client window, give the user experience of a local application even though it is being run remotely. The application will resize itself along with the ThinLinc client window, and closing the application will automatically end the ThinLinc session.
Using tl-single-app in combination with the “Start a program” feature of the ThinLinc client is a good way to test out this functionality. Once you are happy with how this works, you may then want to set up a profile on the ThinLinc server with the same command line, so that users don’t have to enter it into the client each time.
Multi-windowed Applications
The method described above works fine for most single-windowed applications, however some applications consist of multiple windows. Because the entire application is confined to the boundaries of the ThinLinc client, these windows will not show up separately on the local desktop. They will be arranged in an application-dependant manner, within the ThinLinc session:
In this example, The GNU Image Manipulation Program (GIMP) is running in multi-windowed mode, via tl-single-app inside a ThinLinc session. The main window is maximised to cover the entire session, and two floating “toolbox” windows are stacked in front of it. These floating windows can be moved and resized, and are always displayed on top of the main window, since they are higher up in the application’s window heirarchy. This may be acceptable for some workflows, but the floating windows may obscure the main image window in others.
Some applications may create several windows in a “flat” heirarchy, meaning all windows will be maximised and only one - the “foreground” window - visible at a time. Any windows stacked behind the foreground window can still be accessed either by switching between them with Alt+Tab, or clicking the small icon in the top left of the window decoration.
Other Solutions
For situations where tl-single-app does not produce the desired behaviour by default - for example, applications where several windows are required to be visible at once - there may be other solutions. One option is to launch Openbox with a configuration specific to your application, where windows are maximised (or not) depending on some property of that window, for example the title. Another option might be to use an X11-based tiling window manager such as i3. i3 layout trees can be used to specify exactly which windows should be placed where, along with other properties such as size. Detailed instructions on how to do this are outside the scope of this article, but if you have had success with similar setups please feel free to let us know in the comments below.