Launchers are defined with files in /usr/share/applications following Desktop Entry Specification. They are read by Lipstick and Sailjail components.
Sailfish OS specific additions
Desktop Entry Specification allows extending the specification with product specific keys. Sailfish OS uses that to specify some extensions to support certain functions better.
Application sandboxing profile
Application developers can control their app’s sandbox with X-Sailjail section. They may define OrganizationName, ApplicationName and Permissions keys. Additionally it’s possible to disable sandboxing of an application with Sandboxing=Disabled.
OrganizationName and ApplicationName define the D-Bus bus name that the application may own on session bus. This bus name is formed by concatenating the value of OrganizationName, a dot and the value of ApplicationName in this order so that they form a reverse domain name uniquely identifying the application. OrganizationName should contain at least one dot while ApplicationName should not contain any dots. This name can be used for notifications, sharing and D-Bus activation like described below. The values of these keys also define the directories in user home directory that the application may use to store application private data.
Permissions value is a list of Sailjail permissions. Lipstick checks this list of permissions for approval before launching the app.
As of Sailfish OS 4.3.0 there is support for automatically generating D-Bus service files using ExecDBus key in X-Sailjail section. That way it’s possible to have D-Bus activation without shipping such files as part of the application and to have the platform in control of the launching process. These files are generated to /run/user/*/dbus-1/services/ by Sailjail on user session startup and modified whenever a desktop file changes, e.g. when an application is installed, updated or removed. That new key is used the same way as regular Exec key in Desktop Entry section but it enables use of different arguments.
Defining distinct arguments for ExecDBus allows to detect when D-Bus activation is used. This is useful for launching the application first as a background service that doesn’t show a window and then when a suitable trigger method is called on the D-Bus API, a window can be shown. This way just introspecting the D-Bus API doesn’t show a window and interfaces can avoid graphical gliches due to showing a window too early.
Sailfish OS 4.5.0 and later support using org.freedesktop.Application D-Bus interface for opening files and activating windows. However, Sailfish’s implementation extends the specification in two important ways: Firstly, in addition to DBusActivatable=true key in Desktop Entry section, a prefixed custom X-DBusActivatable=true key is also supported. They behave identically. Secondly, Lipstick also supports using D-Bus bus name derived from X-Sailjail section instead of deriving it from the file name of the Desktop Entry file. See Application sandboxing profile above for more information on that bus name derivation. These additions were implemented as currently Sailfish does not use reverse domain name notation for Desktop Entry file names but some tools enforce these rules.
By specifying X-DBusActivatable=true in Desktop Entry section Lipstick can be instructed to call that above-mentioned D-Bus API instead of executing a new process. When Open or Activate are called, they should also activate the window of the application. Failing to do that may lead to users being unable to open the application. Note that Lipstick does not support ActivateAction method currently.
In Sailfish OS 4.3.0 ExecDBus is not considered when validating the arguments for an application launched via D-Bus which limits usefulness of that key. To work around that, the launch arguments used for D-Bus activation must match Exec key in Desktop Entry section. This issue is fixed in Sailfish OS 4.4.0.