The two ways of disabling session management have the same impact on the
session being saved, but there is one behavioural side-effect that
turned out to be less ideal.
By disabling completely we don't follow the session manager telling the
application to quit. That's not something needed with the systemd boot,
but for the legacy boot effectively we were just closing applications by
ripping the X connection away from under them.
Some applications are bad at handling this and this led to a bunch of
crashes or dangling processes at logout.
This reverts commit 9be7dedb87.
CCBUG: 424408
Plasma core is moved away from being a template. This makes it easier
for others to mark themselves as being after. A new readme is added to
explain the design.
This means on logout we'll be gracefully closed down.
All of these are closing down properly anyway, but this makes things a
bit more explicit in case you managed to log out at an awkward point.
Summary:
This brings numerous advantages such as:
- easier admin configuration with drop-ins, overrides and multiple
hooks throughout (and only having to learn one tool)
- session cleanup on exit, avoiding that occasional part where shutdown
hangs
- startup that actually knows when things are up
- race free autostart and DBus activation at once
- logs that rotate are split by service and usable
- resource management through slices and cgroups (the part I want)
Over the past 2 years I've been trying to tidy up and encapsulate the
relevant parts of startup into the binary plasma-session so that we can
just runtime swap out that one part and supporting both paths will be
easy.
Support is toggleable via cmake flag, as it seems like it should be a
distro decision, especially as we will require a specific systemd with
the xdg-generator.
KDED/kwin/other services are attached to the relevant repo.
Task T11914
Differential Revision: https://phabricator.kde.org/D28305
squash
Instead of comparing the state of the action to the action name, compare it to the argument the action will invoke it with.
In contrast to checkboxes, which are independent actions with a boolean state, radio menu items all refer
to the same action (e.g. "Zoom") and then pass the new state ("zoom-100", "zoom-200", etc) as target when invoking the action.
CCBUG: 418385
Differential Revision: https://phabricator.kde.org/D27885
According to documentation [1] a menu item has a target attribute, which is "the parameter to pass when activating the action".
Furthermore, the action "Activate" method specifies "If the action activation requires a parameter then this parameter must
be given in the second parameter (av).". Also implements a TODO in the code.
[1] https://wiki.gnome.org/Projects/GLib/GApplication/DBusAPI
CCBUG: 418385
Differential Revision: https://phabricator.kde.org/D27884
Xaver Hugl
Laurent Montel
l10n daemon script
Volker Krause
Alexander Lohnau
Nicolas Fella
Ahmad Samir
Weng Xuetian
David Edmundson
Kai Uwe Broulik