It's dark for me.

Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 680(Build:0)
CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Works correctly for me. WDM/Explorer Personalization -> Colors -> 'Dark' color sense.  LibreOffice Tools -> Options -> Appearance "LibreOffice Themes" lb selected to 'Automatic'--with or without 'Enable application theming' checked.

In 'Automatic', change between Light -> Dark, and Dark -> Light of WDM/Explorer color sense correctly toggles the LO app frame to follow the color sense.

=> WFM

=-testing-=

Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Likewise for a recent build of master against 26.8 
TB103 2025-12-16
Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 680(Build:0)
CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

(In reply to Buovjaga from comment #1)
> It's dark for me.
> 
> Version: 26.8.0.0.alpha0+ (X86_64)
> Build ID: 680(Build:0)
> CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster
The issue of light title bar in dark mode happens on my system in the sample provided by MS article. But, the above Github project gives a dark title bar anyway!

Searching for DWMWA_USE_IMMERSIVE_DARK_MODE gives no result, but it turned out that the magic value 20 is used directly:

$ git grep -n DwmSetWindowAttribute
vcl/win/window/salframe.cxx:301:    DwmSetWindowAttribute(hWnd, DWMWA_USE_IMMERSIVE_DARK_MODE, &bDarkMode, sizeof(bDarkMode));

I have created a patch for using symbolic constant instead, although it should be improved to handle the old value 19 (instead of 20) for previous Windows versions:

tdf#145759 Use DWMWA_USE_IMMERSIVE_DARK_MODE
https://gerrit.libreoffice.org/c/core/+/195910

Then, I searched for the cause of difference on my system, and I found that this is actually a Windows option:

Settings > Personalization > Colors > Show accent color on title bars and window borders [x]

Deactivating this option makes LibreOffice title bar dark in dark mode. Having the the option activated prevents DWMWA_USE_IMMERSIVE_DARK_MODE to work. On the other hand, it is possible to override that by setting the title bar color manually:

  COLORREF dark = RGB(32, 32, 32);
  DwmSetWindowAttribute(hWnd, DWMWA_CAPTION_COLOR, &dark, sizeof(dark));

(In reply to Hossein from comment #3)

> Then, I searched for the cause of difference on my system, and I found that
> this is actually a Windows option:
> 
> Settings > Personalization > Colors > Show accent color on title bars and
> window borders [x]
> 
> Deactivating this option makes LibreOffice title bar dark in dark mode.
> Having the the option activated prevents DWMWA_USE_IMMERSIVE_DARK_MODE to
> work. 

Mystery solved!  Yes, my Win11 (25H2) Settings -> Personalization -> Colors UI DWM panel had the 'Show accent color on title bars and window borders' setting at default 'Off', so disabled and WFM.

I know Caolán had to hack at the "undocumented" win32 Dark mode issue on Windows a fair bit to get something functional at 7.4 for bug 118320, and tweaked things with the AllowDark:ForceLight:ForceDark UI override for bug 153229 once it was out of experimental. Was only applicable to > Windows 10 and well before we dropped Win7/8.1 support. In other words as things stand the DWM color support is a *bodge*.

But IIUC the '20' value for DWMWA_USE_IMERSIVE_DARK_MODE came in for Windows 11 > 22000 (21H2) and Windows 10 > 2004 (20H1) and is now "documented" in the Win11 SDK for win32 based applications.  

Making the "undocumented" '19' for Windows 10 builds, prior to 20H1, actually irrelevant at this point?

(In reply to V Stuart Foote from comment #4)
> Making the "undocumented" '19' for Windows 10 builds, prior to 20H1,
> actually irrelevant at this point?
IMO it can be relevant, if we want to support older Windows 10 versions. At the moment, I see "Windows 10" as the requirement to run LibreOffice, and nothing restrictive about the version.

System Requirements > Microsoft Windows
https://www.libreoffice.org/get-help/system-requirements/#windows

Therefore, it IS relevant IMO. But, I will need to install older Windows versions to actually test it.

(In reply to Hossein from comment #5)
> IMO it can be relevant, if we want to support older Windows 10 versions. At
> the moment, I see "Windows 10" as the requirement to run LibreOffice, and
> nothing restrictive about the version.
> 
> System Requirements > Microsoft Windows
> https://www.libreoffice.org/get-help/system-requirements/#windows
> 
> Therefore, it IS relevant IMO. But, I will need to install older Windows
> versions to actually test it.

True, but this is just one aspect of Dark color sense support with win32/c++ that Microsoft had not transitioned well. Yes we *could* test for Windows 10 < 2004 (20H1) but what is the percentage of users that would actually assist? And of those how many on "legacy" unsupported Windows 10 builds would actually attempt to use the os/DE Dark mode color?  Most Windows users are *not* going to pay for LTSB/LTSC support with same question if any of them would be using LibreOffice, or attempting to work in a Dark color sense?

Actually would be much better to declare Windows 10 < 2004 20H1 as unsupported. We have done similar for multiple macOS release builds (admittedly for compiler reason) so simple precedent already for changes in Microsoft API.