Exec may or may not be set to full path in the .desktop file for the window
manager, still it is like brute-force guess
note that the default in KSMServer::selectWm() is just kwin (filename) but
programs are (usually) looked for first in PATH (QProcess does that now for
example)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
if it crashes a startup error will be shown via `xmessage`, there will
be not window manager (most likely) at that point and many things will
not work as expected.
ksmserver cannot be restarted for example, drkonqi is not option either
because attempting to report a bug will open a browser but the backtrace
cannot be copied (the browser window will be on top of any other window
if it launches with no way to switch to the drkonqi window), etc.
in other words - the best thing that can be done is log the backtrace to
the system log (the ksmserver debug area has to be configured for that)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
doubles as performance optimization by reusing the already created
interface (klauncherSignals member)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
now that phase 2 is properly done (see
86082941ab933b36fb7df267f3abd2625757f4ba in kdelibs repo) it could
block for a few seconds
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
if Xrender is not found a fatal message will be issued by the top-level
CMakeLists file because it is required by KWin compositor for example
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
for some reason KSMShutdownFeedback::stop() was not doing anything when the
KWin effect was taking care of the logout effect but KWin also does not
apply the effect to windows other than the one created by ksmserver
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the effect is very much bound to the window manager (KWin) because if
applications require attention (such as confirmation to cancel any
pending changes) their window or any dialog they pop may have to be
raised, will have to be focused and not be grayed out
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the window manager itself may want to do something session management
related (KWin does) and as such ksmserver has to be in operational state
before the window manager is killed
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
note that connecting to signals after the process is started (which is also
auto-deleted) as was done in KSMServer::launchWM() could result in a race
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
unless compositor is not active it is not even used (KWin has logout
effect for that) and there is a curtain effect as fallback
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by the time ksplash gets the X11 events for startup phases the startup
process is (and should be) done, especially after the display
configuration is done and the monitor is ready to output thus ksplash
does not really indicate much
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
org.kde.kded service is now not started by kdeinit4 (the program that owns
org.kde.klauncher) nor by KDateTime (indirectly by KSystemTimeZones) and
that was the assumption in KSMServer. note that there is no emission for
kded phase done from ksmserver which ksplash checks for
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
