Created attachment 160908 [details] No desktop widget transparency See attached screenshot that compares the backgrounds of a widget's panel popup and a desktop widget. The desktop widget isn't transparent at all.
I investigated this bug. Ultimately the issue is that the Plasma is supposed to be using the "translucent/" plasma theme directory when Contrast Effect is enabled, and yet it isn't. This was fiddly in Plasma 5 already; in Wayland, we could only check for Contrast Effect upon startup, meaning that if the user changed the setting, the plasma theme would not be updated accordingly. In X11 there is an EffectWatcher that does update the value if the user changes it. In Plasma 6, the EffectWatcher doesn't work for me; I wasn't able to find out why. However the bigger issue is that it looks like KWindowSystem is not meant to be able to detect effects being on/off anymore (maybe since effects are now plugin?). This means that we are unable to check for Contrast Effect even on startup. If we want to preserve the functionality from Plasma 5 as is, I need to figure out a new way for p-f to check when Contrast Effect is on/off. I'm also wondering whether we want to preserve this distinction at all, instead of having a single plasma theme for both Contrast Effect enabled/disabled. This would simplify the code significantly and make it easier to maintain the Plasma Theme. The idea was (iirc) that when Contrast Effect is off the transparent elements (e.g. panel) need to be a bit more opaque than usual, to preserve readability. However, we *already* offer the same level of transparency in both SVGs (normal one, and translucent/ one, both for panel and for dialogs). Thus, I would suggest to drop translucent/ entirely.
Thanks for investigating! Personally I believe that transparency without blur never makes sense, as readability can become quite bad. In my ideal world, the Background Contrast effect disappears and gets rolled into the Blur effect, if needed. Then when the Blur effect is on, Plasma window/dialog backgrounds becomes slightly transparent to accommodate that blur, and when the Blur effect is off, all that stuff becomes completely opaque. Ideally this opacity could be done programmatically, rather than swapping out dedicated sets of opaque or transparent SVGs. So I think I'm agreeing with you.
I don't agree with having svgs made transparent programmatically. how much is transparent and what elements are should always be artist decision. for breeze itself would work, because the background is a featureless rounded rectangle but there are thousands of themes on the store that we promise to still support. there might be a border the author doesn't want transparent, or on the contrary a more opaque inner zone with a very translucent border around, it's a theme engine with some (even if not much) flexibility which shouldn't make particular assumptions. Now, i wouldn't be particularly opposed on dropping either translucent or solid so either normal->solid, then translucent overrides or normal->translucent with solid overrides. this would drop some elements of existing themes but they would continue to work okay The most retrocompatible of the two would be normal->translucent with solid overrides.
*** Bug 493939 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1215
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1216
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4884
Git commit cb00a034c5156f3fad1cb51ad39187eaba8b1fc8 by Marco Martin. Committed on 07/11/2024 at 08:32. Pushed by mart into branch 'master'. Fix of desktop applets transparency Fix the transparency of desktop applets when the kwin contrast effect is enabled on X11 when the contrast effect availability changes and/or compositing available changes, event compress the setting of the appropriante KSvg selectors (opaque, translucent...) previously the contrast effect was not initialized correctly at plasma start, but was read only on the effect enabled change, so in order for it to pick the correct svg, the effect had to be disabled and reenabled again while plasma was running also, the current state only managed the X11 case but not Wayland. This commit fixes the X11 part. M +1 -4 src/plasma/CMakeLists.txt R +52 -24 src/plasma/private/contrasteffectwatcher.cpp [from: src/plasma/private/effectwatcher.cpp - 050% similarity] R +16 -7 src/plasma/private/contrasteffectwatcher_p.h [from: src/plasma/private/effectwatcher_p.h - 059% similarity] M +36 -32 src/plasma/private/theme_p.cpp M +8 -9 src/plasma/private/theme_p.h https://invent.kde.org/plasma/libplasma/-/commit/cb00a034c5156f3fad1cb51ad39187eaba8b1fc8
Git commit 6bc55a2ef5b1fe5b6c5e0d52ba96514fbda9f0fc by Marco Martin. Committed on 07/11/2024 at 08:32. Pushed by mart into branch 'master'. Add needed background contrast properties for background effects In order for the plasma applets on desktop to replicate the background effect that popups have, they need to know the effect paramaters contrast, intensity and saturation With that with a MultiEffect they can do a background blur for desktop appelts that looks identical to popups M +4 -0 src/plasma/theme.h https://invent.kde.org/plasma/libplasma/-/commit/6bc55a2ef5b1fe5b6c5e0d52ba96514fbda9f0fc
Git commit 982f3e54f9f47749cd5a0e9ef200c893416ffc3b by Marco Martin. Committed on 07/11/2024 at 08:32. Pushed by mart into branch 'master'. effect watcher: Add wayland support ContrastEffectWatcher used to support only X11, add wayland support for watching the availability of the contrast effect M +10 -0 src/plasma/CMakeLists.txt M +35 -2 src/plasma/private/contrasteffectwatcher.cpp M +3 -1 src/plasma/private/contrasteffectwatcher_p.h https://invent.kde.org/plasma/libplasma/-/commit/982f3e54f9f47749cd5a0e9ef200c893416ffc3b
Git commit f2ca73d8bbe1aab340a47927b99d262ef2e3ada9 by Marco Martin. Committed on 07/11/2024 at 08:55. Pushed by mart into branch 'master'. Applets: fix Applets background effects Desktop applets are supposed to use the exact same background effects as popups, not only blurring, but altering the brightness, contrast and saturation of the wallpaper wit hthe same parameters the kwin effect is using Depends from https://invent.kde.org/plasma/libplasma/-/merge_requests/1216 before:  after:  M +32 -16 components/containmentlayoutmanager/qml/BasicAppletContainer.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/f2ca73d8bbe1aab340a47927b99d262ef2e3ada9