]> git.ipfire.org Git - thirdparty/systemd.git/blame - docs/DESKTOP_ENVIRONMENTS.md
tree-wide: fix spelling errors
[thirdparty/systemd.git] / docs / DESKTOP_ENVIRONMENTS.md
CommitLineData
31c68e02
BB
1---
2title: Desktop Environment Integration
3category: Concepts
4layout: default
5---
6
7# Desktop Environments
8
9NOTE: This document is a work-in-progress.
10
11## Single Graphical Session
12
13systemd only supports running one graphical session per user at a time.
14While this might not have always been the case historically, having multiple
15sessions for one user running at the same time is problematic.
16The DBus session bus is shared between all the logins, and services that are
17started must be implicitly assigned to the user's current graphical session.
18
19In principle it is possible to run a single graphical session across multiple
20logind seats, and this could be a way to use more than one display per user.
21When a user logs in to a second seat, the seat resources could be assigned
22to the existing session, allowing the graphical environment to present it
23is a single seat.
24Currently nothing like this is supported or even planned.
25
26## Pre-defined systemd units
27
28[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html)
29defines the `graphical-session.target` and `graphical-session-pre.target` to
30allow cross-desktop integration. Furthermore, systemd defines the three base
31slices `background`, `apps` and `session`.
32All units should be placed into one of these slices depending on their purposes:
33
34 * `session.slice`: Contains only processes essential to run the user's graphical session
35 * `apps.slice`: Contains all normal applications that the user is running
36 * `background.slice`: Useful for low-priority background tasks
37
38The purpose of this grouping is to assign different priorities to the
39applications.
40This could e.g. mean reserving memory to session processes,
41preferentially killing background tasks in out-of-memory situations
86b52a39 42or assigning different memory/CPU/IO priorities to ensure that the session
31c68e02
BB
43runs smoothly under load.
44
45TODO: Will there be a default to place units into e.g. `apps.slice` by default
46rather than the root slice?
47
48## XDG standardization for applications
49
50To ensure cross-desktop compatibility and encourage sharing of good practices,
51desktop environments should adhere to the following conventions:
52
53 * Application units should follow the scheme `apps-<launcher>-<ApplicationID>-<RANDOM>.service`,
54 e.g. `apps-gnome-org.gnome.Evince-12345.service`,
55 `apps-flatpak-org.telegram.desktop-12345.service` or `apps-KDE-org.kde.okular-12345.service`.
56 * Using `.service` units instead of `.scope` units, i.e. allowing systemd to
57 start the process on behalf of the caller,
58 instead of the caller starting the process and letting systemd know about it,
59 is encouraged.
60 * If no application ID is available, the launcher should generate a reasonable
61 name when possible (e.g. using `basename(argv[0])`). This name must not
62 contain a `-` character.
63
64This has the following advantages:
65 * Using the `apps-<launcher>-` prefix means that the unit defaults can be
66 adjusted using desktop environment specific drop-in files.
67 * The application ID can be retrieved by stripping the prefix and postfix.
68 This in turn should map to the corresponding `.desktop` file when available
69
70TODO: Define the name of slices that should be used.
71This could be `apps-<launcher>-<ApplicationID>-<RANDOM>.slice`.
72
73TODO: Does it really make sense to insert the `<launcher>`? In GNOME I am
74currently using a drop-in to configure `BindTo=graphical-session.target`,
75`CollectMode=inactive-or-failed` and `TimeoutSec=5s`. I feel that such a
76policy makes sense, but it may make much more sense to just define a
77global default for all (graphical) applications.
78
79 * Should application lifetime be bound to the session?
80 * May the user have applications that do not belong to the graphical session (e.g. launched from SSH)?
81 * Could we maybe add a default `apps-.service.d` drop-in configuration?
82
83## XDG autostart integration
84
85To allow XDG autostart integration, systemd will ship a cross-desktop generator
86to create appropriate units for the autostart directory.
87Desktop Environments will be able to make use of this simply by starting the
88appropriate XDG related targets (representing e.g. content of the
89`$XDG_CURRENT_DESKTOP` environment variable to handle `OnlyShowIn/NotShowIn`).
90The names and ordering rules for these targets are to be defined.
91
92This generator will likely never support certain desktop specific extensions.
93One such example is the GNOME specific feature to bind a service to a settings
94variable.
95
96## Startup and shutdown best practices
97
98Question here are:
99
100 * Are there strong opinions on how the session-leader process should watch the user's session units?
101 * Should systemd/logind/… provide an integrated way to define a session in terms of a running *user* unit?
102 * Is having `gnome-session-shutdown.target` that is run with `replace-irreversibly` considered a good practice?