https://bugs.kde.org/show_bug.cgi?id=362531
--- Comment #13 from Leslie Zhai <[email protected]> --- (In reply to Thomas Lübking from comment #12) > KWindowSystem is ok, see https://bugs.kde.org/show_bug.cgi?id=364641#c6 > It's a simple race condition - you check the state before starting to > monitor it, thus run into a gap and perpetuate the wrong idea until the next > change. Query the state (in doubt once more) *after* connecting to the > change signal. Hi Thomas, Thanks for your reply! long time no see ;-P Yes, when plasmashell ran before kwin's ContrastEffect initialized, the atom might be isNull https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/effectwatcher.cpp#L50 Then, of course, it might NOT received the KDE special X11 event - _KDE_NET_WM_BACKGROUND_CONTRAST_REGION https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/effectwatcher.cpp#L75 So it would NOT emit effectChanged, and ThemePrivate could not received such SIGNAL to change backgroundContrastActive's default (often is false) value https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/theme_p.cpp#L108 As Niels experienced, the theme type was NOT QStringLiteral("/translucent/") https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/theme_p.cpp#L315 My monkey patch is just set backgroundContrastActive to always true in ThemePrivate's construction, without considering whether or not kwin's ContrastEffect enabled, so how to avoid such race condition issue? I argue that the key point is kwin, the effects side, it needs to ask plasmashell to re-render theme... and KWindowEffects::isEffectAvailable and plasma-framework's EffectWatcher should be more robust. Please give me some advice to point out my mistake, thanks a lot! Regards, Leslie Zhai -- You are receiving this mail because: You are watching all bug changes.
