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