Bug 511346

Summary:	Use both Qt and platform API in KColorSchemeWatcher
Product:	[Frameworks and Libraries] frameworks-kguiaddons	Reporter:	Ilya Fedin <fedin-ilja2010>
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	nicolas.fella
Priority:	NOR
Version First Reported In:	6.18.0
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=496174 https://bugs.kde.org/show_bug.cgi?id=492593
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Ilya Fedin 2025-10-29 23:44:54 UTC

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.

Comment 1 Ilya Fedin 2025-11-02 20:23:49 UTC

Nicolas, what do you think about that? I can create a MR if that's acceptable.

Comment 2 Nicolas Fella 2025-11-05 20:35:01 UTC

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

Comment 3 Ilya Fedin 2025-11-05 20:50:12 UTC

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...

Comment 4 Nicolas Fella 2025-11-05 21:05:39 UTC

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

Comment 5 Nicolas Fella 2025-11-05 21:10:00 UTC

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