Description: When changing dark/light mode for LibreOffice, the instant change is undesirable, and one has to restart LibreOffice to see the complete change. Steps to Reproduce: 1. Start LibreOffice 2. Change the theme to "Light" if LibreOffice is in dark mode (and vice versa) from "Tools > Options > LibreOffice Themes". Actual Results: Only some of the UI elements are changed into light mode. Others remain the same, until you restart LibreOffice. Also, there is no mention that one should restart LibreOffice. Expected Results: Change of theme should happen instantly. You can try changing dark/light mode from Windows "Settings > Personalize > Choose your mode", and see it change dark/light mode instantly, even in LibreOffice. Also, one may see a similar change happening in a demo win32 application below: (requires building with Visual Studio) Darkmodelib – Win32 Library for Dark Mode Support https://github.com/ozone10/darkmodelib/ Reproducible: Always User Profile Reset: No Additional Info: Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 20; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 204753 [details] Half dark, half light, switiching from dark to light Switching from dark to light theme had made only some of the UI elements light.
We have bug 166870 open to suppress the need for LibreOffice restart, so isn't this a duplicate? Though I guess since this is response for the os/DE color settings Dark|Light toggle, its not really a response to changes to our Appearance theme selection. But personally on Windows, I prefer that we always restart to *ensure* the UI is fully stable before resuming work. And I don't agree with bug 166870 as part of LibreOffice appearance theme support. I'd even go so far as to say we *should* block automatic mode toggle, and require the restart, rather than the current response to users DWM color settings Dark/Light selection. Assert more control over the color mode results for LibreOffice by forced restart. No question that completely handling the DWM/Explorer color sense Dark|Light "Dark mode" response is needed and worthwhile. I don't see need for LibreOffice restart as blocking that, rather we should detect the mode change and trigger the restart prompt. But then as for bug 164656 I'd much prefer that we move to implementing a VCL back end for Windows. Hopefully with better widget support than provided by MS SDK for native win32/c++, e.g. implement qt6 based libs and weld. Gain the ability to control all the UI elements without requiring so many exceptions for non-handled elements missing win32 widget support.
I guess in the general case this is an issue as some elements do not respond to DWM Dark|Light color sense changes. I still have concerns that the only reliable response is to block and require LO restart on DWM color theme change.