https://bugs.kde.org/show_bug.cgi?id=496802
--- Comment #23 from Ilya Fedin <fedin-ilja2...@ya.ru> --- > Am I to read your post that KDE applications, despite respecting qt5ct and > qt6ct prior now have it as feature that they ignore it and can only be > configured with kde-systemsettings. That's right that it's ignoring qt6ct but that wrong that it can only be configured with systemsettings. It rather can only be configured with a portal which should be implemented by your DE (i.e. your DE should have light/dark theme switch and KDE apps should automatically respect it choosing either Breeze Light or Breeze Dark). If your DE doesn't have such a feature or you're not using a DE then you can use darkman to set light/dark preference. Additionally, there's a way for QPAs to integrate with the kcolorscheme framework. Upstream qt6ct doesn't implement it but qt6ct-kde implements but only when you select a compatible color scheme (the ones marked as `(KColorScheme)`). > why does kate load ~/.config/qt6ct/colors/Darkgrey.conf but then does nothing > with it? It works by Qt's plugin functionally which can load any third party code. Qt loads qt6ct code that reads it but then kcolorscheme framework overrides it with a compatible color scheme. > Surely this cannot be intended behavior as a feature and has to be a bug? And > if it be intended, it seems like removing a useful feature that was their > prior. It's intended, yeah. There was a long standing problem that KDE applications look weird outside of KDE (e.g. being half-light, half-dark at the same time). That's because KDE apps partially use Qt's QPalette while partially its own KColorScheme format which has more colors than QPalette. Now the framework forcefully overrides Qt's palette to one of the standard KColorSchemes (Breeze Light/Dark) unless the plugin (such as the kde one or qt6ct) sets a compatible color scheme (a KColorScheme). -- You are receiving this mail because: You are watching all bug changes.
