SUMMARY You can't, for some reason, use Adaptive Transparency in Plasma Styles like Breeze if you turn their ContrastEffect value off in their metadata. Having ContrastEffect on makes it work however. STEPS TO REPRODUCE 1. Edit /usr/share/plasma/desktoptheme/default/metadata.desktop to disable ContrastEffect 2. Ensure AdaptiveTransparency is on 3. Apply the Style again and maximise a window OBSERVED RESULT Adaptive Transparency... doesn't appear to work. EXPECTED RESULT Adaptive Transparency would make the panel opaque irregardless. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE neon 5.21.2 (available in About System) KDE Plasma Version: 5.21.2 (I compiled it with the Adaptive Transparency patches from master) KDE Frameworks Version: 5.79.0 (again, compiled Plasma Framework with Adaptive Transparency patch from master) Qt Version: 5.15.2 ADDITIONAL INFORMATION Yeah, it's actually technically stable Plasma, although I compiled it WITH all the commits relating to Adaptive Transparency that niccolove linked me, and the extra commit in Plasma Workspace that wasn't by niccolove relating to said feature. I didn't know what to therefore count the version as to prevent confusion so I just marked it as 'master' since it's a feature from master.
It's kinda intentional, the very translucent backgrounds need blur contrast to be used at all (that's since plasma 5.0, is just more obvious now) the rationale is a conscious decision on ensuring that popup contents are actually readable
(In reply to Marco Martin from comment #1) > It's kinda intentional, the very translucent backgrounds need blur contrast > to be used at all (that's since plasma 5.0, is just more obvious now) > > the rationale is a conscious decision on ensuring that popup contents are > actually readable Wouldn't be that sure, for this use-case, since Adaptive Transparency, well, makes stuff opaque. Not allowing it when contrast is off does the complete opposite of your rationale when a window's maximised.
...'sides, themes like the Plasma Style Feren OS uses don't have contrast on but still are opaque enough by design to give decent contrast.
Seems like this needs to be documented somewhere, or else un-done. Since adaptive transparency is explicitly opt-in, I think it's reasonable to allow people to shoot themselves in the foot to achieve outlandish results with their themes (I mean that's the point of themes, right? /s).
Fixed it with https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/212
Git commit 1b9b03529b5f1da1872b07d18a0daf7230899fbf by Dominic Hayes. Committed on 11/03/2021 at 20:34. Pushed by ngraham into branch 'master'. Change ContrastEffect check to AdaptiveTransparency in A.T. check Fix Contrastless Plasma Styles not being able to use Adaptive Transparency by changing the check, for ContrastEffect being enabled in the Plasma Style to instead check if AdaptiveTransparency is enabled in the Plasma Style, for determining if Adaptive Transparency should be available. FIXED-IN: 5.81 M +1 -1 src/plasma/private/theme_p.cpp https://invent.kde.org/frameworks/plasma-framework/commit/1b9b03529b5f1da1872b07d18a0daf7230899fbf