On NixOS, autologin bypasses cosmic-greeter and instead launches start-cosmic
directly. The XDG_SESSION_DESKTOP variable previously wasn't set hence, which
would break functionality like session commands ("Power Off") in the launcher.
I could not find any consistent documentation on _which_ environment
variables a DE should populate. GNOME just imports everything[0] from
the current DE-startup-session. KDE imports some DE and KDE specific
variables but again, this isn't defined anywhere (that I could find)
on places like <freedesktop.org>. So instead, lets just update
existing ones.
[0]: d14f6db15e
Move the systemctl import-environment call after keyring setup so the
SSH_AUTH_SOCK variable exists before being imported into the user
service manager. Remove the earlier duplicate import block.
Our "privileged sockets" support in cosmic comp has never been enforced
by default, and predates the Wayland security context protocol. That
should cover sandboxed clients, while we can't really secure against
non-sandboxed clients.
We also rely on the DBus socket-activated portal backend having access
to "privileged" protocols now.
So it makes sense to remove this.
The $WAYLAND_DISPLAY and $DISPLAY are prone to change between `greetd`'s
initialization and the user's login. Therefore, update these environment
variables so systemd services and/or d-bus services use the correct
values post login.
environment variables
The goal is to update the environment variables for the user's systemd
session **and** the services listening on user's d-bus session.
Until now, the variables were updated using the `import-environment`
environment command of `systemctl`. But, it would only be executed if
systemd was present on the host system. Leaving the variables on the
d-bus side either uninitialized or with incorrect values.
Therefore, instead of using `systemctl`, use the
`dbus-update-activation-environment` command to initialize/update the
environment variables for user's d-bus session but also for user's
systemd session. This is done by passing the `--systemd` option.
When systemd is not detected, the command doesn't fail, it simply
doesn't update the variables for user's systemd session. And since a
systemd user session doesn't exist, no harm no foul.
