Bug 434202

Oh jeez. I suppose this is because we adjusted the transparency settings in the Breeze Plasma theme which lives in Frameworks, but the feature it supports is only in Plasma 5.22. So people using Plasma 5.21 with the latest Frameworks (i.e. all users of Arch-based distros and openSUSE Tumbleweed) now see a higher level of transparency when windows are maximized than is intended.

Frameworks 5.80 has not actually been released yet, so we have 4 days to revert it and prevent releasing the bug to users.

We could revert and re-commit it in the Frameworks version that Plasma 5.22 depends on (5.82). This would re-introduce the bug for one month, since the Frameworks dependency version is typically released a month before the Plasma version it supports.

Or we could revert the change and only re-add it to the version of Frameworks that's aligned with Plasma 5.22's release date (5.83). This would technically break the dependency though. Perhaps we could change Plasma's Frameworks dependency version to 5.23.

Regardless, I really really really hate how the Plasma Breeze theme lives in Frameworks. For KF6, we've gotta move it out and put in a Plasma-release-schedule-aligned repo.

It looks like we will be able to revert just the transparency changes to the Breeze Plasma theme and request a re-spin of plasma-framework to pick up the change so we can avoid shipping it to users before the final release of Frameworks 5.80.

After this, we can re-merge the transparency change in time for Frameworks 5.83, which will be shipped to users at around the same time as Plasma 5.22.

Not bug janitor found a merge request that might be related ;)
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/211

Git commit 3701b184d85e715a2e56bb751f6b724c6e7d74db by Nate Graham, on behalf of Dominic Hayes.
Committed on 09/03/2021 at 22:31.
Pushed by ngraham into branch 'master'.

Revert 4d4db0b199780d8e3a94594fb72739565cd3919d's theme changes

Undoes the theme changes in that commit since they got pushed too
early in the Frameworks release cycle to be effectively Plasma 5.22
exclusive, saddling users on 5.21 with increased transparency all the
time with no way to turn it off. This was not the intended user
experience.

This commit will be reverted in time to be released with Frameworks 5.83,
which will align with the release of Plasma 5.22.

M  +3    -3    src/desktoptheme/breeze-dark/metadata.desktop.cmake
M  +3    -3    src/desktoptheme/breeze-light/metadata.desktop.cmake
M  +3    -2    src/desktoptheme/breeze/metadata.desktop.cmake
M  +9    -9    src/desktoptheme/breeze/translucent/dialogs/background.svg
M  +25   -25   src/desktoptheme/breeze/translucent/widgets/panel-background.svg
M  +9    -9    src/desktoptheme/breeze/translucent/widgets/tooltip.svg
M  +18   -18   src/desktoptheme/breeze/widgets/plasmoidheading.svg

https://invent.kde.org/frameworks/plasma-framework/commit/3701b184d85e715a2e56bb751f6b724c6e7d74db

(In reply to Nate Graham from comment #1)
> Or we could revert the change and only re-add it to the version of
> Frameworks that's aligned with Plasma 5.22's release date (5.83). This would
> technically break the dependency though. Perhaps we could change Plasma's
> Frameworks dependency version to 5.23.
One thing to keep in mind: Not every distribution is going to drop Plasma 5.21 just because 5.22 is out. In Gentoo e.g., we have a habit of keeping the latest Plasma 5.xx.5 release in stable branch until the next Plasma .5 is ready. During that time, new Frameworks versions may be stabilised once or twice.

Now we have stable: Plasma 5.20.5 / Frameworks 5.77 / Release Service 20.08.3.
Frameworks 5.80 would normally be scheduled for stabilisation 30 days from now, then likely either 5.82/83, 5.85/86... so for a brief time maybe Plasma 5.21.5 will be paired with even Frameworks 5.85 in stable for our users, until 5.22.5 is ready.

And during all that time stable users may decide to unmask any unstable Frameworks version in between, because that is something they can easily do (even if they lose stable support ofc).

Long story short, this means we will likely need to backport the adaptive panel opacity support to Plasma 5.21.5 unless we want to break with our usual schedule or just risk some users may end up with this bug by their own choice (of mixing a stable Plasma with unstable Frameworks).

I see.

This reinforces my belief that the theme should live in plasma-workspace, not plasma-framework. :)

However in the meantime, you can backport the feature to 5.21 by cherry-picking these two commits:
- https://invent.kde.org/plasma/plasma-desktop/-/commit/6fb37dc0260c298bc35ec5e39399aa1f31693e79
- https://invent.kde.org/plasma/plasma-workspace/-/commit/7db8d5ee551f30576588d31470fe287b6ad2adcd

...and then revert https://invent.kde.org/frameworks/plasma-framework/commit/3701b184d85e715a2e56bb751f6b724c6e7d74db

I am planning to introduce these backports with Plasma 5.21.5 and Frameworks 5.82.0 downstream in lockstep.

Are you aware of any fixes happening in that area since it was introduced?

Yes. You will want to cherry-pick:
- https://invent.kde.org/frameworks/plasma-framework/-/commit/950a78f2255ddc772718a6f0a1b6dd998daf7dfb
- https://invent.kde.org/plasma/plasma-workspace/-/commit/1cf02aad96bfe650a1f4d1465ae15234205fb061

Then everything should work properly.

Thank you very much for your support.

These MRs also look mildly related to me:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/855
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/457

Probably, though those haven't been merged yet.