Created attachment 152034 [details] Screenshot STEPS TO REPRODUCE 0. Use Breeze Dark 1. Open Systemsettings 2. Click on Breeze 3. Click apply OBSERVED RESULT "Appearance" on the left keeps having a white font inherited from Breeze Dark. The same happens vice versa, i.e. Breeze Dark --> Breeze. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220911 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Graphics Platform: Wayland
Can reproduce, weird! This doesn't happen when changing global themes in the Global Themes KCM; only when using the items on the Quick Settings page.
Created attachment 152490 [details] Screenshot: KInfocenter I can reproduce the same issue for KInfoCenter: 0. Set theme to Breeze 1. Open KInfoCenter 2. Go the Energy section 3. Change the global theme from Breeze to Breeze Dark or interchange Breeze <--> Breeze Dark. So this seems to be a Breeze, Kirigami or Qt issue?
^ Reproduced on 5.25.5 Wayland and 5.26.80 (git master) Wayland
I also noticed the same issue, when changing the accent color: All colors change, but the one for the "Appearance" item.
*** Bug 464858 has been marked as a duplicate of this bug. ***
*** Bug 465356 has been marked as a duplicate of this bug. ***
It seems like this behavior is not particularly related to the "Appearance" category, rather it's about the first element shown in the ListView. This can be demonstrated by editing any other category inside "../kde/src/systemsettings/categories" so it's "X-KDE-System-Settings-Parent-Category" is "rootcategory". Then change the "X-KDE-Weight" of the appearance category to be some high value (e.g. 99) so it's not the first in the ListView. After encountering this bug: reducing the systemsettings app to it's minimal size and scrolling all the way down and then up again deletes and re-creates the appearance delegate, giving it the correct text color. More importantly once the delegate is re-created it will always have the correct color even after further theme changes. It's strange that only the very first delegate observes this behavior, and my QT-fu isn't advanced enough to troubleshoot the underlying issue. That being said I might have a fix for the symptoms ready soon.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/systemsettings/-/merge_requests/202
*** Bug 470261 has been marked as a duplicate of this bug. ***
*** Bug 470287 has been marked as a duplicate of this bug. ***
Upon re-testing, this appears to be fixed in Plasma 6 already!
Here's a "minimal" reproducible example with Kirigami.ScrollablePage. It's still broken for me with KF6 and Qt 6.5.1 https://invent.kde.org/frameworks/kirigami/-/snippets/2691 It's "minimal" in quotes because Kirigami itself it doing a lot of magic. The snippet works correctly with Kirigami.Page as root component, so that means it's particularly ScrollablePage that does some unspeakable things that break theming
Can reproduce with that minimal example. Re-confirming, but downgrading the severity for now since the issue is at least not affecting System Settings anymore, which was the most user-visible example of it