https://bugs.kde.org/show_bug.cgi?id=496174
--- Comment #42 from Ilya Fedin <fedin-ilja2...@ya.ru> --- > On my laptop, I did not. Laptop never had KDE installed. Maybe I just didn't > have the "prefer dark" (1) in the portal set. That's exactly what I meant. Right now kcolorscheme sets Breeze Dark on "prefer dark" or Breeze Light with any other one. > re sol 1. I'd like to inquire on how exactly one would do that? You just open the "Colors" page in system settings app, click on the pencil button in any color scheme, edit it and then "Save as". Then you should be able to apply it via qt6ct-kde. That's the only way to set it right now on non-KDE but I guess it could also be discussed to add an official way. My kcolorscheme MR adds one for "no preference" on portal but it seems you use "prefer dark". For that case, I guess separate keys for light/dark scheme are needed... > re sol 2. you mean opt out of the non-KDE logic or the KDE logic? Here I > think we just need to opt out of the KDE color scheme manager. It would make > the most sense to me. Every QT app would look uniform if none of them > override the QPalette except the theme engine. I mean to add a way to restore the pre-6.6 state, when QPalette was not overridden. But it still won't use QPalette everywhere as there are places KColorScheme class is used explicitly and that's why all that logic was added: usually pre-6.6 state was leading to things like light text on light background in places using KColorScheme while dark background everywhere else but it was somehow invisible with you customizations. Given that KColorScheme has more color roles than QPalette, QPalette couldn't be mapped to KColorScheme. Only the other way around (what is done by forcing Breeze color scheme). The problem is that kvantum then somehow overrides palette again but not in all places (perhaps because it has no control on KColorScheme framework) so you see what you see. -- You are receiving this mail because: You are watching all bug changes.
