docs/_concepts/DESKTOP_ENVIRONMENTS.md

   1 ---
   2 title: Desktop Environment Integration
   3 category: Concepts
   4 layout: default
   5 SPDX-License-Identifier: LGPL-2.1-or-later
   6 ---
   7
   8 # Desktop Environments
   9
  10 NOTE: This document is a work-in-progress.
  11
  12 ## Single Graphical Session
  13
  14 systemd only supports running one graphical session per user at a time.
  15 While this might not have always been the case historically, having multiple
  16 sessions for one user running at the same time is problematic.
  17 The DBus session bus is shared between all the logins, and services that are
  18 started must be implicitly assigned to the user's current graphical session.
  19
  20 In principle it is possible to run a single graphical session across multiple
  21 logind seats, and this could be a way to use more than one display per user.
  22 When a user logs in to a second seat, the seat resources could be assigned
  23 to the existing session, allowing the graphical environment to present it
  24 is a single seat.
  25 Currently 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)
  30 defines the `graphical-session.target` and `graphical-session-pre.target` to
  31 allow cross-desktop integration. Furthermore, systemd defines the three base
  32 slices `background`, `app` and `session`.
  33 All 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
  39 The purpose of this grouping is to assign different priorities to the
  40 applications.
  41 This could e.g. mean reserving memory to session processes,
  42 preferentially killing background tasks in out-of-memory situations
  43 or assigning different memory/CPU/IO priorities to ensure that the session
  44 runs smoothly under load.
  45
  46 TODO: Will there be a default to place units into e.g. `app.slice` by default
  47 rather than the root slice?
  48
  49 ## XDG standardization for applications
  50
  51 To ensure cross-desktop compatibility and encourage sharing of good practices,
  52 desktop 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
  74 This 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
  80 TODO: Define the name of slices that should be used.
  81 This could be `app-<launcher>-<ApplicationID>-<RANDOM>.slice`.
  82
  83 TODO: Does it really make sense to insert the `<launcher>`? In GNOME I am
  84 currently using a drop-in to configure `BindTo=graphical-session.target`,
  85 `CollectMode=inactive-or-failed` and `TimeoutSec=5s`. I feel that such a
  86 policy makes sense, but it may make much more sense to just define a
  87 global 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
  95 To allow XDG autostart integration, systemd ships a cross-desktop generator
  96 to create appropriate units for the autostart directory
  97 (`systemd-xdg-autostart-generator`).
  98 Desktop 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
 102 binaries in an `ExecCondition=` line.
 103
 104 However, this generator is somewhat limited in what it supports. For example,
 105 all generated units will have `After=graphical-session.target` set on them,
 106 and therefore may not be useful to start session services.
 107
 108 Desktop 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
 110 systemd service file for startup.
 111
 112 ## Startup and shutdown best practices
 113
 114 Question 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?