1--- 2title: Desktop Environment Integration 3category: Concepts 4layout: default 5SPDX-License-Identifier: LGPL-2.1-or-later 6--- 7 8# Desktop Environments 9 10NOTE: This document is a work-in-progress. 11 12## Single Graphical Session 13 14systemd only supports running one graphical session per user at a time. 15While this might not have always been the case historically, having multiple 16sessions for one user running at the same time is problematic. 17The DBus session bus is shared between all the logins, and services that are 18started must be implicitly assigned to the user's current graphical session. 19 20In principle it is possible to run a single graphical session across multiple 21logind seats, and this could be a way to use more than one display per user. 22When a user logs in to a second seat, the seat resources could be assigned 23to the existing session, allowing the graphical environment to present it 24is a single seat. 25Currently nothing like this is supported or even planned. 26 27## Pre-defined systemd units 28 29[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html) 30defines the `graphical-session.target` and `graphical-session-pre.target` to 31allow cross-desktop integration. Furthermore, systemd defines the three base 32slices `background`, `app` and `session`. 33All units should be placed into one of these slices depending on their purposes: 34 35 * `session.slice`: Contains only processes essential to run the user's graphical session 36 * `app.slice`: Contains all normal applications that the user is running 37 * `background.slice`: Useful for low-priority background tasks 38 39The purpose of this grouping is to assign different priorities to the 40applications. 41This could e.g. mean reserving memory to session processes, 42preferentially killing background tasks in out-of-memory situations 43or assigning different memory/CPU/IO priorities to ensure that the session 44runs smoothly under load. 45 46TODO: Will there be a default to place units into e.g. `app.slice` by default 47rather than the root slice? 48 49## XDG standardization for applications 50 51To ensure cross-desktop compatibility and encourage sharing of good practices, 52desktop environments should adhere to the following conventions: 53 54 * Application units should follow the scheme `app[-<launcher>]-<ApplicationID>[@<RANDOM>].service` 55 or `app[-<launcher>]-<ApplicationID>-<RANDOM>.scope` 56 e.g: 57 - `app-gnome-org.gnome.Evince@12345.service` 58 - `app-flatpak-org.telegram.desktop@12345.service` 59 - `app-KDE-org.kde.okular@12345.service` 60 - `app-org.kde.amarok.service` 61 - `app-org.gnome.Evince-12345.scope` 62 * Using `.service` units instead of `.scope` units, i.e. allowing systemd to 63 start the process on behalf of the caller, 64 instead of the caller starting the process and letting systemd know about it, 65 is encouraged. 66 * The RANDOM should be a string of random characters to ensure that multiple instances 67 of the application can be launched. 68 It can be omitted in the case of a non-transient application services which can ensure 69 multiple instances are not spawned, such as a DBus activated application. 70 * If no application ID is available, the launcher should generate a reasonable 71 name when possible (e.g. using `basename(argv[0])`). This name must not 72 contain a `-` character. 73 74This has the following advantages: 75 * Using the `app-<launcher>-` prefix means that the unit defaults can be 76 adjusted using desktop environment specific drop-in files. 77 * The application ID can be retrieved by stripping the prefix and postfix. 78 This in turn should map to the corresponding `.desktop` file when available 79 80TODO: Define the name of slices that should be used. 81This could be `app-<launcher>-<ApplicationID>-<RANDOM>.slice`. 82 83TODO: Does it really make sense to insert the `<launcher>`? In GNOME I am 84currently using a drop-in to configure `BindTo=graphical-session.target`, 85`CollectMode=inactive-or-failed` and `TimeoutSec=5s`. I feel that such a 86policy makes sense, but it may make much more sense to just define a 87global default for all (graphical) applications. 88 89 * Should application lifetime be bound to the session? 90 * May the user have applications that do not belong to the graphical session (e.g. launched from SSH)? 91 * Could we maybe add a default `app-.service.d` drop-in configuration? 92 93## XDG autostart integration 94 95To allow XDG autostart integration, systemd ships a cross-desktop generator 96to create appropriate units for the autostart directory 97(`systemd-xdg-autostart-generator`). 98Desktop Environments can opt-in to using this by starting 99`xdg-desktop-autostart.target`. The systemd generator correctly handles 100`OnlyShowIn=` and `NotShowIn=`. It also handles the KDE and GNOME specific 101`X-KDE-autostart-condition=` and `AutostartCondition=` by using desktop-environment-provided 102binaries in an `ExecCondition=` line. 103 104However, this generator is somewhat limited in what it supports. For example, 105all generated units will have `After=graphical-session.target` set on them, 106and therefore may not be useful to start session services. 107 108Desktop files can be marked to be explicitly excluded from the generator using the line 109`X-systemd-skip=true`. This should be set if an application provides its own 110systemd service file for startup. 111 112## Startup and shutdown best practices 113 114Question here are: 115 116 * Are there strong opinions on how the session-leader process should watch the user's session units? 117 * Should systemd/logind/… provide an integrated way to define a session in terms of a running *user* unit? 118 * Is having `gnome-session-shutdown.target` that is run with `replace-irreversibly` considered a good practice? 119