[plasmashell] [Bug 473289] Desktop widgets' background aren't transparent in Plasma 6

2023-08-14 Thread Marco Martin
https://bugs.kde.org/show_bug.cgi?id=473289

--- Comment #3 from Marco Martin  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 473289] Desktop widgets' background aren't transparent in Plasma 6

2023-08-12 Thread Nate Graham
https://bugs.kde.org/show_bug.cgi?id=473289

Nate Graham  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

--- Comment #2 from Nate Graham  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 473289] Desktop widgets' background aren't transparent in Plasma 6

2023-08-12 Thread veggero
https://bugs.kde.org/show_bug.cgi?id=473289

veggero  changed:

   What|Removed |Added

 CC||niccolo.venera...@gmail.com

--- Comment #1 from veggero  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.