Summary:
KSMServer has two modes, the slightly ancient mode (XSMP), and the
really ancient legacy mode (XSM).
When startup was rewritten in 96a595f1b8
we accidentally dropped the call that invokes restore of the legacy
session as well as the normal mode.
BUG: 404318
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D19028
Summary:
We don't need to introspect at runtime as KDED installs the interface
XML file.
Oddly KDED's package is called KDED not KF5KDED, hence the separate
find_package, I don't know if that's a bug in frameworks or not.
Test Plan: Compiles
Reviewers: #plasma, romangg
Reviewed By: #plasma, romangg
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D16628
Summary:
kcminit had a slot to start processing something and a signal to emit
when it's finished.
For DBus that's quite bad practice as it can leave you hanging in the
case of a kcminit crashing. It's better to use the return of the
original call to signal when something is done.
From ksmserver we can then just use DBus timeouts set on the interface
than a secondary timer.
We also remove a pointless blocking call to kcminit introspecting
everything, if kcminit is not running it will return with an error
immediately which is no slower than checking first if it's not running
and faster if it is.
Test Plan:
Logged in
Session logs showed kcminit ran
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: zzag, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D16587
Summary:
The old code checked ksmserver->defaultSession in the Startup
constructor before ksmserver was set up by main.cpp
This refactor moves it to the job, so we'll be checking if we're
restoring or not after ksmserver has been set up by main.cpp as well as
making the initial code path a bit clearer.
Test Plan:
Logged in with session restore
Logged in with a default session
Reviewers: ahartmetz
Reviewed By: ahartmetz
Subscribers: ahartmetz, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D16550
Summary:
The code is effectively 3 startup phases each of which has some parallel
methods that need to be complete before moving onto the next phase.
The old code had a tonne of methods all of which tracking what state
we're in and trying to start the next method in the chain handling
things out of order.
This simplifies everything into 3 composite kjobs. A lot more classes,
but each one tiny with the flow more readable.
Code should be effectively the same. The startup sound is moved ever so
slightly earlier to be when phase 2 starts rather than just after
kcminit2 finishes (midway through the old phase 2), but no significant
behavioural changes here.
Test Plan: Logged in with session restore and without
Reviewers: #plasma, apol
Reviewed By: apol
Subscribers: apol, broulik, anthonyfieroni, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D16231
Summary:
Everything related to Plasma startup goes in Startup everything relating
to X session management stays in KSMServer. Restoring the window
manager currently stays inside ksmserver as it passes the session ID as
an argument and at various points checks if something the client is the
WM.
Relevant methods move to server.cpp to keep one class per cpp file.
KSMServer gains some signals as it can no longer call the startup methods
directly to continue the process.
This is part of a cleanup series in ksmserver. (The friend class will disappear
in the next commit)
Behaviour should remain identical.
Test Plan: Logged in on X
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D16225
Summary:
ksmserver autostart had a system where processes, such as plasma, could
block the startup phase from moving on.
It is currently entirely unused.
It's very difficult to use properly, plasmashell has to block startup
before ksmserver moves on to phase 1. Racey at best.
I did hack it to work, and it does make a surprising positive
improvement to bootup. Worth exploring the idea properly, but implemented
better.
We should be able to get the same results by
blocking and waiting for the DBus name in the autostart desktop file to
become registered rather than having a ksmserver-specific solution.
Test Plan: Compiles, can still login
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D16042
Since Phonon 4.9, this code fails to play a login sound if the sound
file is specified as absolute file path (without "file://"). The reason
is that QUrl() treats the parameter as Url (not as file path), and this
only accidentally worked with earlier Phonon versions but not any more.
This patch uses QUrl::fromUserInput() instead to create a QUrl from the
string in the settings file, which fixes the problem.
This is the same change as
https://phabricator.kde.org/R289:9db06adc8114163f401417064b07772139bc36bc
in knotifications.
A more detailed explanation of the problem can be found in
https://bugs.kde.org/show_bug.cgi?id=337276#c12 .
BUG: 392725
FIXED-IN: 5.12.5
Differential Revision: https://phabricator.kde.org/D12606
Summary:
It's an overly slow call and it gets in the way on a process that needs
to be responsive
Test Plan: Still boots
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9090
Merge commit 6e6f1beda4 appeared
to not include the headers included in the original revert in
the 5.8 branch, causing stable branch build failures on Neon,KDE
and Kubuntu CIs. So add these back to 5.9 branch.
KRun::runApplication will show blocking error dialogs if it fails to
find the executable
This means we don't autostart the next app, which could be fatal if it
comes before...
Summary:
...kwin/plasma
We shouldn't be having blocking calls in ksmserver it can deadlock
And even in the best case we'd still end up blocking ksplash for 30
seconds
We then port to KProcess which was part of the motivation behind the
patch as it
has better stdout handling
This reverts commit 0f19e92f3e.
BUG: 379254
Also added port of autostarting applications to KProcess
It has better stdout handling
Test Plan: Logged in, still got my main session
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5618
Follow-up to the previous commit. KProcess has saner defaults for simply
launching an app and being done with it, no lost stdout/stderr or even SIGPIPE.
CCBUG: 369391
CCBUG: 370528
The "move" (copy in fact) of the autostart code from klauncher simply
switched to QProcess. This resulted in a number of problems, as the incorrect
handling of .desktop file command if it had placeholders (worked around
already), kdeinit is no longer used (not sure how much that matters nowadays)
and finally QProcess simply eats all stdout/stderr of all such processes
(which, when daemonized, can lead even to the processes getting SIGPIPE'd).
If the application to start is a KService, simply launch it as such.
BUG: 369391
BUG: 370528
Normally kWin is launched simply as "kwin" ("kwin_x11", whatever), but
in some cases it's restart command may be "/usr/bin/kwin", most notably
when KWin restarts itself after a crash. Failing to recognize this client
as the WM leads to KWin starting without any session management restoring.
CCBUG: 377756
Follow-up to the previous commit. KProcess has saner defaults for simply
launching an app and being done with it, no lost stdout/stderr or even SIGPIPE.
CCBUG: 369391
CCBUG: 370528
The "move" (copy in fact) of the autostart code from klauncher simply
switched to QProcess. This resulted in a number of problems, as the incorrect
handling of .desktop file command if it had placeholders (worked around
already), kdeinit is no longer used (not sure how much that matters nowadays)
and finally QProcess simply eats all stdout/stderr of all such processes
(which, when daemonized, can lead even to the processes getting SIGPIPE'd).
If the application to start is a KService, simply launch it as such.
BUG: 369391
BUG: 370528
Normally kWin is launched simply as "kwin" ("kwin_x11", whatever), but
in some cases it's restart command may be "/usr/bin/kwin", most notably
when KWin restarts itself after a crash. Failing to recognize this client
as the WM leads to KWin starting without any session management restoring.
CCBUG: 377756
Follow-up to the previous commit. KProcess has saner defaults for simply
launching an app and being done with it, no lost stdout/stderr or even SIGPIPE.
CCBUG: 369391
CCBUG: 370528
The "move" (copy in fact) of the autostart code from klauncher simply
switched to QProcess. This resulted in a number of problems, as the incorrect
handling of .desktop file command if it had placeholders (worked around
already), kdeinit is no longer used (not sure how much that matters nowadays)
and finally QProcess simply eats all stdout/stderr of all such processes
(which, when daemonized, can lead even to the processes getting SIGPIPE'd).
If the application to start is a KService, simply launch it as such.
BUG: 369391
BUG: 370528
Normally kWin is launched simply as "kwin" ("kwin_x11", whatever), but
in some cases it's restart command may be "/usr/bin/kwin", most notably
when KWin restarts itself after a crash. Failing to recognize this client
as the WM leads to KWin starting without any session management restoring.
CCBUG: 377756
Summary:
It's in case klauncher fails to return from autostart, however autostart
is now handled by ksmserver in process - so this will always be called.
I failed to notice it when I did the initial move
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3054
Summary:
BUG: 372153
CHANGELOG: Repaired autostart of desktop files with place holders
FIXED-IN: 5.8.4
Test Plan:
- add firefox.desktop to autostart
- make sure it autostarts without errors on next login
I really wish we had a framework to test this in isolation :/
Reviewers: davidedmundson
Reviewed By: davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3454
Summary:
Currently ksmserver sends DBus calls to klauncher to autostart services.
This patch brings all autostarting into the ksmserver process, putting
all autostart code together, and improving Plasma/Frameworks separation
(change requested by David Faure) with the long term goal of removing
this from klauncher; with a longer term goal of maybe even killing
klauncher.
We don't get two things autostarting as without ksmserver sending the
signals, klauncher does nothing.
Autostart.cpp code is copied verbatim so there's no breakage.
Test Plan: Logged in, got plasma and krunner and so on.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: mart, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2544
According to Git / SVN history research, it was last used by KDE in
KDE 1. It seems like other toolkits also stopped using it 10-20 years
ago. It should have little to no practical relevance anymore.
I've found some documentation of legacy XSM session management from
1992, and the first copyright year of the XSMP spec (what we're
currently using) is 1993.
Also, XSM was removed from GNOME's gnome-session in 2005, rationale
and short discussion here:
https://mail.gnome.org/archives/desktop-devel-list/
2005-July/msg00527.html
with the following objections:
- Firefox doesn't support XSMP (long fixed)
- CDE on Solaris doesn't support XSMP (oh well...)
- Motif applications don't support XSMP
On kde-core-devel and kwin, nobody cared too much.
Consider XSM "accidentally" broken now ;)
https://marc.info/?l=kde-core-devel&m=144857647812257https://marc.info/?l=kde-core-devel&m=144976915400658
There is a utility called xsmproxy which comes from X.org.
It talks legacy XSM to clients and XSMP to an XSMP compliant
session manager and can therefore maybe hopefully make session
management of dinosaur applicatons sort of work.
It seems like that one received its last major modification
in 2003.
There is also some XSM related code in KWin that I will remove next.
QProcess::startDetached doesn't work on shell scripts, presumably
because it tries to daemonize them.
Porting to QProcess seems to fix this. As KSMServer stays around forever
this shouldn't result in any behavioural change.
REVIEW: 124838
Commit f913e251fe removed this, due to a porting bug: both klauncher
(XDG autostart using .desktop files) and ksmserver (kde-specific scripts)
were ported to look at the same directory (~/.config/autostart),
leading to double autostart. The right fix, however, is to use
a different directory for scripts, I called it ~/.config/autostart-scripts.
BUG: 338242
REVIEW: 124534
With its current architecture, KNotification can cause crashes on logout
due to use of Q_GLOBAL_STATIC and threads and Phonon and cleanup by main
thread. So this replaces the KNotification-in-a-thread with Phonon
directly.
This is exactly what KNotification would do. This is for the time being
until the crash on logout is sorted out.
Additionally, this also fixes logout sound which was missing before.
This uses normal KNotification as at that point we don't need to be
threading or anything, so KNotification is just safe.
REVIEW: 123834
If ksmserver is started in a session with WAYLAND_DISPLAY
and/or WAYLAND_SOCKET being exported we can assume that the Xserver is an
Xwayland server. In that case the wayland compositor is also the window
maager. Thus starting a window manager would either fail or create severe
havoc in case it succeeds in replacing the running window manager.
REVIEW: 123444
KSMSERVER_STARTUP_DEBUGl is not defined, meaning this code currently
exists in our ksmserver.
if you have 2 instances of gedit, konqueror and kspaceduel open you get
an error message saying drat. I'm not sure why.
This feature is now obsoleted as kspaceduel doesn't exist any more.
REVIEW: 123283
If klauncher can't launch any of the services within the phase2
autoStart2Done will be never called, hence leaving ksmservice in an
invalid status.
Since at this moment is almost impossible for klauncher to make sure
that autoStart2Done is always called we have to add a work around the
same way we have done with all the other phases.
This workaround is specially useful since it is in phase2 where we
launch third party stuff.
Currently KLauncher is responsible for starting all of the autostart
files. It intelligently starts only the files which should be started in
the KDE environment.
Once this is done, KLauncher then decides to also start all the files
in the autostart folder, but does that without checking which should be
started. I'm not sure why both KSMServer and KLauncher are overlaping
and doing the same thing. But it seems that KLauncher is the correct
place to do this. Specially since ksmserver uses kioclient5 in order to
start the applications.
BUG: 335878
REVIEW: 118977
This reverts commit c2f4588431.
Apparently this can cause the login sequence to wait for PulseAudio and
can delay the startup quite considerably, so temporarily reverting.
REVIEW: 118636
CCBUG: 335948
Conflicts:
ksmserver/plasma_workspace.notifyrc
runUserAutostart should look into users dirs,
and the port from KGlobalSettings::autostartPath overlooked this,
so system location was used instead
BUG: 335970
David Edmundson
Laurent Montel
Wolfgang Bauer
Friedrich W. H. Kossebau
Aleix Pol
Rik Mills
Luboš Luňák
Luboš Luňák
Harald Sitter
Oliver Henshaw
Andreas Hartmetz
David Faure
Martin Klapetek
Martin Gräßlin
Hrvoje Senjan
Àlex Fiestas
Vishesh Handa
Lukáš Tinkl
Jonathan Riddell