the style KCM for example emits changes via
KGlobalSettings::self()->emitChange() however it does not wait for the
KGlobalSettings::settingsChanged() signal (which means settings are
reloaded) before running krdb, font and palette settings are likely subject
to this race-condition but for now that will do
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
note that the only way to set EffectsEnabled, EffectFadeMenu,
EffectFadeTooltip and EffectAnimateCombo was manually (by editing the
~/.katana/share/config/kdeglobals config file) because there is no GUI for
those config options but there is for the graphics effects level
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
note that the KMessageWidget animation is a fade effect so
KateFadeEffect was doing what KMessageWidget already has the feature
for, grow/shrink effect is not a thing
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>
effects for example may have their own selection (the startupfeedback
effect used to claim _KDE_STARTUP_FEEDBACK for example) so if other
window manager wants to claim selection/atom owned by KWin effect effects
have to be deinitialized before disowning the window manager selection
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>
the 4sec delay removed in 4560049c4a was
essentially fence for the setup, with that gone plasma (or any application
automatically started) initial checks for compositor (or anything window
manager related) could fail
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the compositor is global static with inter-dependancy on the workspace
global static which access the compositor - what could go wrong with
timers, signals global statics and X11 atom ownership?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
