Work a while ago was started here: https://github.com/KDE/plasma-systemd-integration
It stalled somewhat. Partly due to some systemd things, partly due to the fact that some minor details which were missed due to the previous state of plasma startup.
I think our best bet is to work on this upstream rather than separately.
Aleix and I have been working on startup trying to make it possible, now startup is properly documented and the memory is fresh it's a good time to do this properly.
Gnome have since completed their port: https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/
Behaviour has to be opt-in.
Possibly completely hidden till after the next LTS?
Though use of units is something Munich people have requested, so maybe LTS is good. Dunno.
ActionsTODO
[ ] Port all instances of startup.updateLaunchEnv && klauncher.setLaunchEnv
to include programatic equivalent of "dbus-update-activation-environment --systemd"
maybe it's worth a helper function to wrap all update calls into 1.
[/] Change startplasma to instead of calling plasma-session executable to request plasma-target
[ ] Figure out when startplasma has to quit. Currently it waits for plasma-session.
Solution in plasma-systemd-integration is not workable (it's a while loop and a sleep)
[ ] All units need to not have SESSION_MANAGER env during the QApp constructor, otherwise they'll be torn down by ksmserver. But they do need it set for anything they spawn (or use my new qcoreapplication sessionmanager enabled which is in Qt5.14)Things to decide / ramblings:
plasma-session is written so that startup.cpp could be a single shot that quits when launching finishes, and shutdown.cpp could be simple DBus activated helper..[ ] Figure out when startplasma has to quit. Currently it waits for plasma-session.
the only reason it stays alive is so that plasmasession knows when to quit...
If startplasma had a way to tell it to die then shutdown.cpp could be ported to that?Solution in plasma-systemd-integration is not workable (it's a while loop and a sleep)
Maybe needs some brainstorming
[ ] [ ] Ideally all units need to not have SESSION_MANAGER env during the QApp constructor, otherwise they'll be torn down by ksmserver. But they do need it set for anything they spawn.
[ ] We need to figure out how to terminate the units gracefully.
Eliasp bound them to the lifecycle of ksmserver...clever but I want to make ksmserver more optional
Gnome's situation is super complicated: https://guadec.ubicast.tv/videos/managing-gnome-sessions-with-systemd_85843/ 30 minutes in
[ ] Add units for
[ ] We need to figure out how to call kcminit phase 1 & 2 properlys 1 and 2 separately
[ ] HandleWhat do we do with old-schooltyle autostartt .desktop files
GUse generators? Currently gnome uses an executable
[ ] Handle ksmserver session restore properly. I changed it so it had a DBus call to trigger restore, so we can have a unit with type=singleshot exec=dbus-send org.kde.ksmserver /KSsmserver restoreSession (I hope)
[ ] make kglobalaccel use dbus activation if relevant. That way systemd hooks can kick in if relevant and spawn as a service correctly.
Could mean we teach KService about DBus activation, it is part of the FD.O spec of .desktop files, or we do something custom in kglobalaccel, that might be better for actions anyway.
----
Syncing with gnome:
Propose a standard .target symlink that other services can rely on (i.e a desktop.target that is wanted by plasma.target and gnome.target)
Propose a standardised hint in autostart .desktop files for "ignore me when using systemd mode"