On 2 Jun 2023, at 17:26, David C. Partridge <david.partri...@perdrix.co.uk> 
wrote:

I am most unhappy to have to report that I  just had a bug report 
https://bugreports.qt.io/browse/QTBUG-112653 closed WON’T DO for a problem I 
reported with handling of Dark/Light mode switching.

The reason given was that Qt 6.5 won’t support Dark mode on Windows.

This seems more than a bit out of order given the fanfare about support of Dark 
Mode in Qt 6.5 in the announcement and the blog e.g.: 
here<https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5>

David


Hi David,

We do support dark mode on Windows, but not if the native (UxTheme based) style 
is used as that style doesn’t use the palette to render controls, and instead 
relies on the UxTheme system library, which never provides dark-mode assets. 
That’s what Axel tried to communicate in the comment. As you are using Fusion 
as the application style, this limitation doesn’t apply to you, and you will 
get the dark palette in dark mode, and the light palette in light mode.

However, the signal you are handling gets emitted to inform clients that the 
system theme (as seen by the QStyleHints) has changed. The palette changes in 
response to that (often asynchronously, and after giving the current style a 
chance to polish and override the system palette). By the time the signal gets 
emitted, the palette is still the old one. This is by design - the theme 
changes, and the palette changes in response to it.

To do what you intend to do, handle the ApplicationPaletteChange event in your 
UI. You can then evaluate the value of QStyleHints::colorScheme API to decide 
how you want to modify your style sheet.

Volker

_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Reply via email to