User:Eliasp/Drafts/Plasma Workspace as systemd user-session: Difference between revisions
| Line 29: | Line 29: | ||
If the final result is a really fast startup, a splash screen might be not needed anymore. | If the final result is a really fast startup, a splash screen might be not needed anymore. | ||
If the startup still takes "enough" time to show a splash screen, ksplashqml needs to be reworked to be able to deal with a parallelized startup. | If the startup still takes "enough" time to show a splash screen, ksplashqml needs to be reworked to be able to deal with a parallelized startup. | ||
=== DBus-activatable applications === | |||
''IRC Log (#kde-devel, 2014-10-03)'' | |||
<nowiki> | |||
[13:57:06] <eliasp> some applications (Kate, Konsole, …) started naming their desktop file in /usr/share/applications/ as org.kde.$application.desktop … is this something which should be streamlined across all KF5 based applications now? | |||
[14:24:41] <frinring> eliasp, rdieter: it allows DBus-activatable applications, see also http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Not yet supported by kdeplatform, but surely will one day. Needs that naming of desktop file, DBusActivatable=true in desktop file and usage of KDBusService, all that is needed for app-side support | |||
[14:26:45] <eliasp> frinring: ah, awesome… that's something which perfectly fits into my goals for getting systemd user-session support into Plasma… | |||
[14:30:05] <eliasp> frinring: does the application need to do something special when using KDBusService? | |||
[14:30:27] <eliasp> frinring: or does every application using KDBusService automatically fulfill all the requirements? | |||
[14:30:29] <frinring> eliasp: no, just normal KDBusService usage. That installs that interface automatically | |||
[14:30:36] <eliasp> perfect, thanks! | |||
</nowiki> | |||
Revision as of 12:38, 3 October 2014
Plasma Workspace as systemd user-session
Ultimate Goal
The ultimate goal of this project is, to make use of systemd's support for user-sessions wherever possible for running a Plasma Workspace. This support is to be implemented in a way which doesn't get in the way of legacy/cross-platform support, so running a Plasma Workspace without a systemd user-session underneath will still be possible.
What are the benefits?
- Parallelized and faster startup of the Plasma Workspace after login
- More finegrained control over running services
- Increased stability by eliminating existing hacks in startkde, ksmserver, kdeinit, …
- Cleaner definition of dependencies between Plasma Workspace components
- Increased security
- Greatly improved logging by using systemd's journald - goodbye horrible piece of log-target called ~/.xsession-errors
- Better control over system resources/process priorities (e.g. ensure GUI elements are always responsive) via systemd's builtin cgroup control interface
Resources
user-session units for Plasma Workspace
I created some initial user-session units for Plasma Workspace which can be found on GitHub.
Unsorted items
This is a collection of items, notes and other things which need to be taken care of. They need to be investigated and properly documented.
ksmserver
ksmserver does a lot of ugly (from systemd's perspective) things which need to be evaluated:
- tries to start a WM in ksmserver/startup.cpp → launchWM which should be left to systemd
- doesn't register itself as session leader via systemd-logind which breaks a lot of session related functionality. Documented in bug#335390
ksplashqml
Relies on a serial startup of the components, but isn't able to deal with a parallelized startup. If the final result is a really fast startup, a splash screen might be not needed anymore. If the startup still takes "enough" time to show a splash screen, ksplashqml needs to be reworked to be able to deal with a parallelized startup.
DBus-activatable applications
IRC Log (#kde-devel, 2014-10-03) [13:57:06] <eliasp> some applications (Kate, Konsole, …) started naming their desktop file in /usr/share/applications/ as org.kde.$application.desktop … is this something which should be streamlined across all KF5 based applications now? [14:24:41] <frinring> eliasp, rdieter: it allows DBus-activatable applications, see also http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Not yet supported by kdeplatform, but surely will one day. Needs that naming of desktop file, DBusActivatable=true in desktop file and usage of KDBusService, all that is needed for app-side support [14:26:45] <eliasp> frinring: ah, awesome… that's something which perfectly fits into my goals for getting systemd user-session support into Plasma… [14:30:05] <eliasp> frinring: does the application need to do something special when using KDBusService? [14:30:27] <eliasp> frinring: or does every application using KDBusService automatically fulfill all the requirements? [14:30:29] <frinring> eliasp: no, just normal KDBusService usage. That installs that interface automatically [14:30:36] <eliasp> perfect, thanks!