QProcess::start defaults to capturing all output, but that got lost as it is
never read. Set QProcess::ForwardedChannels explicitly where it was missing,
so that output ends up in the correct place again.
(cherry picked from commit d1155030af)
There's no use of static declarations in headers, those result in compiler
warnings. They could be removed envirely after moving one function up a bit.
(cherry picked from commit 6ebbab4778)
It is important that we end plasma-core.target plasma-workspace.target
and graphical-session.target when we log out. graphical-session in turn
closes all other apps and daemons and prevents restarts.
Handling it in systemd gives the least racey option.
graphical-session used to be hanlded in the plasma-ksmserver service
file, but this was removed in 5.24 in a refactor where it caused issues
for Xwayland restarting.
This patch reintroduces the sentinel programs to close down our target,
which in turn take down the other targets. It also removes a complicated
use of templates that in hindsight didn't really solve anything.
BUG: 448492
Testing done:
- logout of wayland shows all targets as inactive, logging in
repeatedly works smoothly
- logout of X11 behaves the same.
- calling systemctl --user stop plasma-kwin_wayland.service closes the
session
- killing ksmserver on wayland does not close the session
- killing ksmserver on X does
(cherry picked from commit 39ecc45e5b)
If invoked on gnome we should always return success
this is because a desktop file that has X-KDE-AutostartCondition
probably has an X-Gnome- equivalent and we only want one to run
this would match non systemd behaviour.
See also: https://github.com/systemd/systemd/pull/22115
(cherry picked from commit 497a3984a9)
KSplash is changed to read which theme to use directly. It's already
linking config and it already loads the default shared config implicitly
so we weren't saving anything having it done by the launcher.
On X11 ksplash is still managed by startplasma-x11 as we can do it
straight away.
For wayland we need to wait till kwin is up so this is done either by
plasma-session or systemd. For systemd the unit is started explicitly so
we can parse the config file, but after the target starting kwin is
started so that the "After=" line works correctly.
ksmserver can crash if xwayland goes down, which currently happens
should kwin restart. With the refactoring this means kwin_wayland
restart handling would regress.
Instead we can tie to kwin wrapper on wayland. This closes after a
graceful shutdown as that instructs kwin to quit.
Currently we have a whole daisy-chain of startplasmawayland-> kwin ->
startplasmawaylandsession -> launching the session.
This was needed as we needed environment variables which previously we
only knew after kwin started.
After some kwin refactoring this is no longer the case, and
kwin_wayland_wrapper will sync it's environment variables to the
appropriate startup environments.
This allows us to move starting kwin_wayland to be systemd managed,
brining resource control, alongside it's classic counterpart
plasma-session.
As we have discussed, this mechanism is considered Plasma-internal, meaning
that we don't have to keep the KServiceTypeTrader stuff around.
To avoid duplicating the KCMs or having to split the kcminit stuff in a separate
binary, symlinks are used to query the available plugins. By having a unified "kcminit"
symbol for the function which will get called, we can drop the need for the
custom property.
Task: https://phabricator.kde.org/T14335
Prequisite for using only embedded json metadata for the KCMs, see https://phabricator.kde.org/T14517
with this, if the configured color scheme was changed, or if the color scheme
file was updated, the colors will be reapplied and the plasma svg cache discarded
save on config the hash of the current color scheme file
the normal defaults cascading mechanism for application colors doesn't work, as header colors would be wrong, so check if colors are missing from kdeglobals and in that case apply the colors from lnf to kdeglobals
Changes how plasma_session works. Instead of just starting the
processes, plays the startup sound and stays around. This process then
gets to be terminated as the session ends.
BUG: 359651
BUG: 433293
Systemd units which are symlinked to the service directory will be in
`linked` or `linked-runtime` state. They are also available and
runnable. This can happen when the package manager uses symlinks to
install systemd units instead of copying them, like on NixOS.
StartPlasma's fontDPI syncs the current font DPI to xrdb, which affects
font DPI for X applications (inc apps run in xwayland)
This is seldom used on wayland as with framebuffer scaling you don't
want to adjust your font DPI, but it is used by some users. As it's
xrdb, it needs to come after Xwayland is started for the wayland case.
The goal of this patch is to move towards killing the
startplasma-waylandsession binary as well as just being better design to
have these things comparmentalised.
kcminit is very early in the boot process before all GUI apps with the
exception of ksplash. I don't think this will make a big difference as
that's just a picture anyway?
From what I can tell these aren't used by anybody, and not something we
want to be using whilst we increase our wayland support.
Grepping through all of KDE, the only usage I found was kde 4's
KApplication and that code is exclusively checking for
"KDE_SESSION_VERSION==4" which will be false anyway.
The version in kdelibs4support checks for the env variable too.
This will avoid name conflicts in the future and emphasizes that
we are in fact dealing with a plasma specific class.
Relates to https://phabricator.kde.org/T12176
The handling of the autostart is exclusively done in plasma.
Also the method of KAutostart do not work cross platform and most apps
simply use the X-KDE-autostart-condition, which is not affected by this MR.
In case we need to configure cross platform autostart logic the KService class
needs to be rewritten anyways. But there is currently no need or plans for it.
By importing this class in plasma-workspace we are more flexible in any case.
Task: https://phabricator.kde.org/T12176
On wayland we don't want to use the env vars as we send the scale via
wl_output scale.
If a user logs into X first we set these in our activation env to a
scaled value. If they then log into wayland afterwards they are still
set. Calling qunsetenv won't work as then we won't remove them from the
activation env.
Arguably it's working round a bug, but we don't have other options.
BUG: 438971
- Remove check for kded and confupdate stages in SplashApp, those setStage()
calls were removed a long time ago[1]
- Rename 'kinit' stage to 'startPlasma', since it's called from startplasma
- Remove startKDEInit(), it was declared but not defined anywhere, most
likely left-over from a previous refactor.
https://phabricator.kde.org/R297:185afa8a3af8002172d8f5d6aa08c57244422a12
The code already checks if the object to add to the container hasn't been
added before, no need for the QSet overhead; (unless the alphabetical order
if required, but I see nothing to support this theory).
"If $XDG_CONFIG_DIRS is either not set or empty, a value equal to
/etc/xdg should be used."
If XDG_CONFIG_DIRS was not set prior to startplasma, which it ordinarily
would not be, then the previous code would set the value to "$newdir:"
which was silly and also wrong as per the spec quoted above. Instead
default to /etc/xdg/.
Also camelCase the variables to follow our coding style.
Fabian Vogt
David Edmundson
Alexander Lohnau
David Redondo
Marco Martin
Aleix Pol
Oxalica F
Henri Chain
Nicolas Fella
Adrien Faveraux
S Page
Ahmad Samir
Harald Sitter