The bug also reported here: https://bugs.archlinux.org/task/45635 After upgrade plasma-framework to 5.12 semi-transparency lost on panels Reproducible: Always Steps to Reproduce: 1. KDE System Settings > Desktop Behavior > Desktop Effects, Disable "Background contrast". 2. Enable "Blur" 3. Update plasma-framework to 5.12 Actual Results: Screenshots available on https://bugs.archlinux.org/task/45635 This bug probably be associated with: https://bugs.kde.org/show_bug.cgi?id=348154 But if for someone the contrast is too small should enable "Background contrast", rather than take away all can enable transparency. For me, with this option disabled, the contrast is sufficient, the same as last comment on https://bugs.kde.org/show_bug.cgi?id=348154 and votes on: https://bugs.archlinux.org/task/45635 Please restore the option to enable transparent when switched off contrast.
This is intended to ensure everything stays readable regardless of wallpaper or contents below dialogs. Please enable the background contrast effect in System Settings -> Workspace Appearance -> Desktop Effects, or chose a theme other than the default one.
Created attachment 93582 [details] panel If this option is enabled transparency is almost invisible. Screenshot I add in attachment
That's actually the way our designers have envisioned the desktop to be, I'm afraid.
Background contrast was supposed to be the effect that ensured everything to be readable by DECREASING the transparency. With the effect disabled, the transparency should be there - it even IS there for a few seconds after disabling background contrast, but disappears afterwards. This simply CAN'T be the intended behavior.
I can confirm it's intended. >With the effect disabled, the transparency should be there With the effect disabled it was deemed unreadable if you also have transparency so it is removed. See https://bugs.kde.org/show_bug.cgi?id=348154 (and we have many duplicate reports)
Created attachment 93583 [details] panel2 So it looked before, I think the contrast is quite sufficient, if for someone is too low may enable improving. >That's actually the way our designers have envisioned the desktop to be, I'm afraid. I do not think that was the plan, because the option was created to improve contrast. If there is an option for improving kotrastu why I have no way worsen him, just completely disables the transparency. Option improve the contrast can be enabled by default, but please to leave her action.
@bartek Find a transparent theme on kde-look. http://kde-look.org/content/show.php?content=170623 This was transparent because of a bug. The theme assumed it was being blurred with this effect, falling back to an opaque one if this effect is not available. Ideally if you want your theme to look different, it should be because you explicitly chose the theme to look different; not as a side effect of breaking something in kwin. It's an option in kwin for performance reasons not aesthetics ones. It wouldn't be fair on others to have the theme change because they made a performance change. Plus having that as the "correct" way to change the theme would not be particularly discoverable.
Hi everyone, I am the reporter on the archlinux bug list. I am confused by the discussion here, so somebody please enlighten me. If the current behavior is intended by the designers of KDE, then what is the purpose of the "Background contrast" effect? I read "Improve contrast and readability behind semi-transparent windows" from the description of the "Background contrast" effect. But the current behavior is: Enable "Background contrast": panels are semi-transparent (but almost invisible) Disable "Background contrast": panels are solid (100% opacity) i.e. enabling "background contrast" will make contrast and readability worse, from my opinion. If the current behavior is indeed intended, then the name and description of this effect need to be changed to something like "Panel background transparency". PS: This bug https://bugs.kde.org/show_bug.cgi?id=337355 is only triggered with "Background contrast" enabled on my system, which is very annoying. PS2: I still want my visible transparent back (could be a slider in the configuration of the "Background contrast" effect) ...
Breeze wants to be near opaque white with slight blurred effect. If that is unavailable it falls back to completely white. For performance puporses configuring this is optional in kwin, as with all plugins. There was a bug that we fixed last release where a certain config setup led to a transparent panel. This is a genuine bug that caused many of our users real problems, and we are not going to reintroduce problems. If you want a transparent panel, you should choose a theme with a transparent panel. I linked to such a theme above.
Created attachment 93594 [details] PKGBUILD The option of increasing and decreasing contrast in the past acted properly, and now does not work - still think it's a regression error. To resolve previously reported errors, enough to to enable "Background contrast" It is not right to take someone functionality used by him, when there is the option of stopping for people who do not want to. I think that this issue will return as the majority of popular distributions Frameworks update to 5.12, as can be seen that a few people is not enough to make a difference. Theme Breeze Transparent - is a bypass the problem that was created earlier unnecessarily. Additionally it looks different than the original. Information for interested undo the changes. You have to apply a reverse patch: http://quickgit.kde.org/?p=plasma-framework.git&a=commitdiff&h=d65c0ed1d07b4fb09643c9401a6697db1282d89e&o=plain For users ArchLinux attach ready PKGBUILD for plasma-framework.
So I'm clear on what you're arguing, in your opinion: 1) we should reintroduce the linked reported bug 2) that the most intuitive way for a user to change this one particular aspect of the theme isn't with the rest of the theme settings, but in some advanced kwin setting?
(In reply to Tomasz C. from comment #10) > The option of increasing and decreasing contrast in the past acted properly, > and now does not work - still think it's a regression error. Could you please describe exactly which option you are referring to? > To resolve previously reported errors, enough to to enable "Background > contrast" > Theme Breeze Transparent - is a bypass the problem that was created earlier > unnecessarily. Additionally it looks different than the original. In which regard does it look different than the original? This can probably be fixed.
(In reply to David Edmundson from comment #11) > So I'm clear on what you're arguing, in your opinion: > > 1) we should reintroduce the linked reported bug No reintroduce, 348154, 337355 - these 'bugs' could be solved by enable the "Blur" and enable "Background contrast" then it looks like attachment 'panel'. As someone wanted to have a more transparent it disable "Background contrast" and had what you see on 'panel2' Both of these options can be turned on by default and there should be more such reports. Or, maybe someone had a problem on the side of the video card or driver, I tried on three different computers with the Intel and worked it as shown in the attachments. The same is true for screenshots of https://bugs.archlinux.org/task/45635 (not mine) > 2) that the most intuitive way for a user to change this one particular > aspect of the theme isn't with the rest of the theme settings, but in some > advanced kwin setting? Working properly option "Background contrast" was satisfactory (for me).
(In reply to Thomas Pfeiffer from comment #12) > (In reply to Tomasz C. from comment #10) > > > The option of increasing and decreasing contrast in the past acted properly, > > and now does not work - still think it's a regression error. > > Could you please describe exactly which option you are referring to? As for the option: "KDE System Settings > Desktop Behavior > Desktop Effects > Background contrast" Before: Enable - see attachment 'panel' Disable - see attachment 'panel2' now: Enable - see attachment 'panel' Disable - panels are solid (100% opacity) Perhaps this explains better comment # 8 Now you can not reach normal way 'panel2' Based on materials from the Internet (screens, video) I think that transparency appears on 'Panel2' is quite popular, and users miss her, but that's my opinion. You can wait for an update frameworks for other distributions and see if it will come true. I think that this report could be left open to avoid duplicates and vote in users, but that's just my suggestion. > > To resolve previously reported errors, enough to to enable "Background > > contrast" > > > Theme Breeze Transparent - is a bypass the problem that was created earlier > > unnecessarily. Additionally it looks different than the original. > > In which regard does it look different than the original? This can probably > be fixed. The lock and logout window.
(In reply to Tomasz C. from comment #14) > Now you can not reach normal way 'panel2' > Based on materials from the Internet (screens, video) I think that > transparency appears on 'Panel2' is quite popular, and users miss her, but > that's my opinion. This is what's called a "feature bug": A technical bug caused a result which was unintended, but liked by some users. We fixed the bug, now those users who liked the looks it caused want it back. We recognized that, but we won't bring back an unintended look, so David created an alternative theme to recreate that look. I fail to see the problem with this. The option is there, it's only a few clicks more. > > > Theme Breeze Transparent - is a bypass the problem that was created earlier > > > unnecessarily. Additionally it looks different than the original. See above, it is not a bypass. It is our recognition that some users liked the unintended previous look. The VDG never had a transparent panel in mind, the "almost but not fully opaque" look as the only intended one. > > In which regard does it look different than the original? This can probably > > be fixed. > > The lock and logout window. They are indeed not transparent, but are you absolutely certain that they were in previous versions? Apart from this, I don't see how Breeze Transparent (which I'm currently using) looks any different from "panel2". If you find any actual differences between Breeze Transparent and what Breeze looked like before with Background Contrast disabled, please point them out so they can be fixed. We do aim to allow users to bring back the previous unintended look with an alternative theme. We will _not_ bring back the unintended look of the previous version to the default theme, because a) It wasn't how it was designed b) It had poor readability, which is a no-go for a default theme
Created attachment 93596 [details] Panel is transparent and also has the blur effect I don't understand the problem. - background contrast on = nearly opaque panel, text readable - background contrast off = transparent panel with blur, possible less readable text It does not make sense for the panel to be completely opaque with background contrast off, because: - a text on an opaque surface is more readable than a text on semi-transparent background - background contrast effect introduces semi-transparency - background contrast states that enabling should improve readability -> this is a contradiction. I'm fine with having to install a transparent theme (please add breeze dark transparent, though), but the contradiction is still there.
> b) It had poor readability, which is a no-go for a default theme Actually, background contrast effect was enabled by default (at least it was on arch linux) and the user had to explicitly disable the effect to get more transparency, so this point is invalid. As for differences, there is one for the desktop switcher (see attachments in a few mins)
Created attachment 93597 [details] desktop switcher with old plasma framework
Created attachment 93598 [details] desktop switcher with breeze transparent
I understand that KDE want to ensure contrast under whatever possible combination of options, and I'm fine with Breeze Transparent Theme. But as Soukyuu and Tomasz C. had pointed out, there is still a contradiction between the behavior and the description of the "Background Contrast" effect. This might not be an issue on the plasmashell's side, but on kwin's side. Should we open another bug to track the description issue?
(In reply to farseerfc from comment #20) > Should we open another bug to track the description issue? Yes, please.
I do not understand why it is better to do the problems many users instead of writing in two reports: "Hi, if you have too much transparency that enable Background contrast" or: "You enabled more transparency and you surprised it's now more?" After all these comments I suppose that will generate more problems by removing the possibility of setting transparent than if it was not removed. This option was already a long time and acted correctly, and many users uses it, and no argument will go to them that it was not meant to be, because it was they liked. Keyword "feature bug" does not appeal to me, because "Background contrast" worked correctly, now includes transparency for a few seconds and then it completely off - it looks clearly like a bug.
> now includes transparency for a few seconds and then it completely off - it looks clearly like a bug. Plasma waits a bit until the compositor and everything has settled before loading new UI graphics to avoid repeated / unnecessary IO.
I've deleted section [ContrastEffect] in Metadata.desktop of breeze theme = solved
*** Bug 352445 has been marked as a duplicate of this bug. ***