SUMMARY Now you can't match Latte & Konsole transparency settings, because math seems to be different (Like one is linear and another one is exponential) STEPS TO REPRODUCE 1. Set Plasma style to Breeze 2. Change color scheme Window background & Konsole window background both to #000000 3. Make sure that Desktop effects - Background contrast is turned off 4. Try to match Latte & Konsole transparency values. OBSERVED RESULT Latte Background opacity 20% / Konsole background transparency 80% https://i.imgur.com/DTqfAxV.png Latte Background opacity 50% / Konsole background transparency 50% https://i.imgur.com/UWZmbzF.png Latte Background opacity 80% / Konsole background transparency 20% https://i.imgur.com/QI3B6Ws.png Latte Background opacity 90% / Konsole background transparency 10% https://i.imgur.com/q6vyhxf.png EXPECTED RESULT Matching values should give equal visual results SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (Stable) (available in About System) KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION I assumed that it is Latte Dock responsible for this mismatch, because for example if you set Menu transparency in Breeze application style to match Konsole it will match. Hopefully that assumption was right, my first bug-report on KDE! :)
Totally irrelevant... Breeze application style and Breeze plasma theme are different. Plasma themes can have different opacity settings than application styles.
Yes of course they can have different opacity settings, but you maybe missed my point - those opacity settings if matched like 50% and 50% should ideally be visually same, ain't it? Now looks like Latte and rest of the system just use different "curves", if it makes sense
(In reply to keybreak from comment #2) > Yes of course they can have different opacity settings, but you maybe missed > my point - those opacity settings if matched like 50% and 50% should ideally > be visually same, ain't it? > > Now looks like Latte and rest of the system just use different "curves", if > it makes sense Plasma Themes are setting their opacity setting in their svg files. That means that by default there are plasma themes that DONOT provide solid visuals for 100% opacity. Latte has add workarounds and extra calculations to succeed in this. So what you are asking is a new better approach for plasma themes that somehow provide values from 0% to 100% opacity. That is not Latte responsibility of course.
Oh i see what you mean, it's more of a feature for overriding Plasma inability... Sorry for misjudge! Maybe you have an idea where such 'feature request' for Plasma itself may be appropriately forwarded on this bug-tracker, in order to at least consider possibility of such improvement?
Can you clarify exactly what improvement you're requesting?
Hi Nate! I'm not at all technical on that matter, but according to Michail that would be: ------ by default there are plasma themes that DONOT provide solid visuals for 100% opacity. Latte has add workarounds and extra calculations to succeed in this. So what you are asking is a new better approach for plasma themes that somehow provide values from 0% to 100% opacity. ------ Which would in a nutshell mean basically ability to have full control of Plasma panels opacity, so Latte would drop workarounds to do that, and all the same opacity values set like for example 50% on panel / 50% on Latte panel / 50% on Konsole would be visually exactly same and use same "curve".
So you want the ability to easily control the opacity of Plasma panels, pop-ups, notifications, etc. In fact this is something that's desired by KDE's VDG and in line with future plans. In particular the use case we're targeting is allowing people to turn all the transparency *off* (without having to use a totally different Plasma theme, of course), but as long as the proposed setting is implemented as a slider rather than an on-off checkbox, it could accommodate your use case too.
I'm ok with adding sliders to plasmathemeexplorer for easier editing of the two values in there. Anything else would be problematic. We cannot have something simultaneously defined by the user and the theme.
If we do that, I think we'll need to put some polish into Plasma Theme Explorer to make it more user-friendly. But yeah, that could work.
@Nate Yeah, sliders and 0-100 values in some config for panel, pop-ups, notification, plasmoids should be a really great experience improvement, as long as they use same "curve" as all rest of opacity settings! @David ----- Anything else would be problematic. We cannot have something simultaneously defined by the user and the theme. ----- You mean it would be technically difficult? From a user perspective i would imagine it as a great option having something like checkbox: [x] Use opacity from theme If unchecked - give user slider controls and use those values.
It is technically difficult to not break existing themes, which will upset artists. There's two alpha sources, the image itself and the background contrast + mask. Then you can't work out what's actual widget transparency in a picture and what's a shadow fading away. Some themes have really strong contrast and work transparently others don't. Also from a UX perspective I want the workflow to be super consistent. If you want to choose a theme you choose a theme, if you want to edit a theme, you edit a theme. I don't think there's a space or a need for something in between for one setting or to treat this differently from any other theme edit. >, I think we'll need to put some polish into Plasma Theme Explorer to make it more user-friendly ack.
I can see some benefits to this for themers. Splitting theme assets in the svg into shadows, an opaque background to control, and overlays (like highlights around the edges that you wouldn't want to lose opacity) would mean that translucent/ and solid/ could have a manually set opacity in the .desktop if there was no need to make new svgs. As few as one svg could be needed and opacity could be adjusted within the file instead of a set for solid/, translucent/, etc.
the transparency of the panel can be easily disabled with a button, why can't the same be done for the other parts of the shell?