Description of problem: Plasma style resets back to dark after changing it on main page in "System Settings". Version-Release number of selected component (if applicable): kf5-plasma-5.88.0-1.fc35.x86_64 How reproducible: Always. Steps to Reproduce: 1. Open "System Settings", select "Dark Theme", click "Apply"; 2. Select "Light Theme", click "Apply" and close "System Settings"; 3. Open "System Settings" again - panel would become dark. Actual results: Panel changes it style to dark. Expected results: Panel should stay light after choosing "Light Theme" in the settings & saving them. Additional info: Bug could be easily reproduced in the VM with Fedora 35 KDE Spin. I'm using F35-KDE-x86_64-LIVE-20211115.iso to reproduce it. Updated to latest package versions of course.
Created attachment 1843629 [details] Fedora 35 KDE Spin.webm Video with live bug demonstration.
According to my findings this bug is caused by the `plasma-workspace-5.3.0-set-fedora-default-look-and-feel.patch`: 1. https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma-workspace.spec#_449 2. https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma-workspace-5.3.0-set-fedora-default-look-and-feel.patch Bug can't be reproduced if this patch is not applied to the package.
The problem appeared on Fedora 34. After changing the theme to a dark setting, they consider that the Brese theme is active and do not allow it to be activated. When you restart the system, the theme changes in the same way. Distorted colors sometimes appear: light background, white text. This is how the main menu looks like and the background with date/time on the panel. In addition, when the light theme is activated, the panel has no transparency. I managed to partially solve the problem by manually editing the ~/.config/plasmarc file by adding a section [Theme] parameter "name=Breeze". After saving the file, transparency is immediately added to the panel. This hack solves the problem before changing the theme through the settings.
Bug & hack demo: https://youtu.be/sa8UkbqBYvM
I suggest renaming the patch to "Breeze theme does not work correctly due to patch" (Russian: Тема Breeze не работает корректно из-за патча).
I'd argue this is an upstream bug (somewhere), please report to them if they're not already aware. It should be possible for downstreams to adjust default theming without side-effects like this.
It's not upstream bug. Issue can't be reproduced on KDE Neon. And I repeat - issue is gone if patch is not applied.
I've already reported it to upstream - no one can reproduce it.
See: https://bugs.kde.org/show_bug.cgi?id=431219.
FWIW I build Plasma from source myself on top of Fedora's packages, so I don't have that patch, and I don't experience the bug.
I participated in the discussion of this bug on the site kde.org. Together with the participants of the Russian Fedora, we investigated the issue. A patch was found in Fedora that breaks the topic. I checked for KDE Neon. There this bug is not reproduced without looking at a similar version of KDE plasma and KDE framework.
Created attachment 1844181 [details] Breeze theme bug
Created attachment 1844183 [details] Breeze theme bug 2
Theme colors are sometimes distorted after restart
Rebuilt from source Drop from spec file: --- ## upstream patches # FIXME/TODO: commented out in need of work: does not applyl cleanly and # potentially causes problems: # Since it appears plasma-workspace no longer uses kinit, the KToolInvocation::invokeTerminal call may not be 100% reliable #%patch100 -p1 -b .konsole-in-contextmenu # FIXME/TODO: it is unclear whether this is needed or even a good idea anymore -- rex %if 0%{?default_lookandfeel:1} %patch101 -p1 -b .set-fedora-default-look-and-feel sed -i -e "s|@DEFAULT_LOOKANDFEEL@|%{?default_lookandfeel}%{!?default_lookandfeel:org.kde.breeze.desktop}|g" \ shell/packageplugins/lookandfeel/lookandfeel.cpp %endif %patch105 -p1 --- Install plasma-workspace-x11-5.23.3-1.fc35.x86_64.rpm. Everything now works correctly.
P.S. "Fedora" theme now doesn't work correctly, but you can use the "Breeze Twight" instead, which is no different.
Dropping that patch also removes breeze twilight from being the default plasma theme (something that is not an option to consider as a fix).
I think I found a bug in our implementation, plasma-workspace.spec contains code: # Populate initial lookandfeel package cp -a lookandfeel lookandfeel.fedora # Overwrite settings to configure twilight mode cp -a lookandfeel.twilight/* lookandfeel.fedora install -m 0644 %{SOURCE15} lookandfeel.fedora/metadata.desktop So, that first step copies "lookandfeel" folder, which happens to be the plasma breeze theme, and then copies twilight contents on top of that. If the intention is to simply use twilight, not sure why we didn't do this instead: # Populate initial lookandfeel package from twilight cp -a lookandfeel.twilight lookandfeel.fedora install -m 0644 %{SOURCE15} lookandfeel.fedora/metadata.desktop I'll ask around and test this.
plasma-workspace-x11-5.23.4 also requires the removal of patches.
Created attachment 1851893 [details] The beauty of the default theme
Created attachment 1851894 [details] The beauty of the default theme 2
Ok, so my findings and assumptions were incorrect. There's still likely an upstream bug *somewhere*, and unless there comes some other (better?) way of implementing a different default theme, we won't be dropping the look-n-feel.patch
The bug is reproduced only on Fedora 33+. It is associated with crooked patches. Other distributions, including KDE Neon, do not contain bugs.
I guess we'll have to agree to disagree whether it's a valid (or crooked) patch or not.
Fixed with the release of 5.24.2
Another update for plasma-workspace brought back the problem. Maybe they fixed another bug - https://bugzilla.redhat.com/show_bug.cgi?id=2053790
*** Bug 2081231 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Can we reopen this please? The bug is back in new versions of KDE. Users still complain about this bug but struggle to file a bug in RHBZ.
*** Bug 2072648 has been marked as a duplicate of this bug. ***