Right now, KColorSchemeWatcher has four backends that are decided compile time: 1. mac 2. qt 3. win 4. xdg I propose to always compile the Qt backend, even if the platform backend is available. First try the value from the platform backend, if it has no preference, fall back to the Qt value (or the other way around?). I'm not sure thhough whether win and mac backends have any sense nowadays as Qt supports querying those platforms' color scheme for a long time... This way, the code will work even on the Linux systems having portals unconfigured if the user has a Qt platform theme plugin supporting the QPlatformTheme::colorScheme API, providing the potential to work correctly for minimal WM setups using qt6ct, gtk3 and etc. Even LXQt doesn't seem to provide color scheme via portal as of now. This is related to https://bugs.kde.org/show_bug.cgi?id=496174 and https://bugs.kde.org/show_bug.cgi?id=492593.
Nicolas, what do you think about that? I can create a MR if that's acceptable.
There's no good reason to use the xdg backend over the Qt one, is there? So we could use that always. Really the only thing KColorSchemeWatcher offers over Qt is PreferHighContrast on Windows for Qt < 6.10
It seems there are people that prefer controlling dark theme preference via portal as well as people not even knowing what portals are (thus not having them in the system or not knowing how to configure them). Qt uses portal for color scheme only in QGnomeTheme, QGtk3Theme (seem to be broken in this one since 6.10.0 though) and QXdgDesktopPortalTheme. I believe trying both is the way to cover more users. And if it was possible to fallback to platform theme's and platform themesl suggested style's palette after those, most users would be covered (would work with Kvantum without any changes in third party projects). But it seems it's not possible to use QStyle (which is in QtWidgets) in KGuiAddons sadly...
I wouldn't want multiple sources of truth in our code. Long term I want to go with https://invent.kde.org/frameworks/kcolorscheme/-/merge_requests/59 How the platformtheme then determines the value is not my concern
Using the palette from the platformtheme (without everything being messed up) is something I want to enable eventually too, but it's not easy given how KColorScheme works