- gnome-session-wayland.target, gnome-session-x11.target: Top-level
targets launched directly to start the regular GNOME (Shell) session
for wayland or x11 respectively.
- gnome-session@.service: Execute gnome-session-binary tself for the
specified (template) session. Is active once
org.gnome.SessionManager is claimed on the bus.
- gnome-session-bus.target: Bound to gnome-session@.service - if
something needs to start after any instance of gnome-session@
starts, it can be After= this one. gnome-settings-daemon uses this.
We also split out gnome-wayland.desktop.in, as it is going to need to
launch gnome-session-wayland.target.
Add a gnome-session-systemd binary to launch the session
This replaces the shell script, and is responsible for uploading the
environment as well as cleaning up if any previous sessions left units
in a failed state.
When there are no required apps (under systemd), let Setenv work
Setenv is a mechanism that some clients - notably mutter - use to set
environment variables for the use of things that are started later. It's
useful because it forwards changes to the systemd activation
environment, which is what units use.
Normally it's only available in early startup, but if starting things is
actually being handled by systemd and not gnome-session, we'll be
RUNNING without the session actually being "up". We were denying
mutter's Setenv calls, which set DISPLAY and WAYLAND_DISPLAY, quite
important environment variables.
Let's try saying that if there are no required apps (the systemd
situation), you can call Setenv while we're already running too.
gsm-systemd: Find user's graphical session, not the current pid's session
If we're started by systemd --user, we won't be in the XDG session of
the user. The session will still exist, and we want to monitor when it
closes so that we know when to die ourselves.
5ced389...
by
Carmen Bianca BAKKER <email address hidden>
