What is the risk if I patch v3.3 to force enable dark theme for Windows 10 LTSC 2019 (based on 1809) (Issue #25529)
Chip Zhang
ChipZhang created an issue (wxWidgets/wxWidgets#25529)Windows 10 LTSC 2019 (based on 1809) is a long term support version with at least 10 years life cycle. While the last Win10 LTSC version, LTSC 2021, has only five years support. This makes LTSC 2019 being the last one that reaches end of life among all Win10 versions. As a result, many enterprise users are using LTSC 2019.
So I am just curious, is it possible to enable dark mode for 1809. I notices the follows in file darkmode.cpp:
// Note: for simplicity, we support dark mode only in Windows 10 v2004 // ("20H1", build number 19041) and later, even if, in principle, it could // be supported as far back as v1809 (build 17763) -- but very few people // must still use it by now and so it just doesn't seem to be worth it. if ( !wxCheckOsVersion(10, 0, 19041) ) { wxLogTrace(TRACE_DARKMODE, "Unsupported due to OS version"); return false; }
I patched this code to check against 17763 (1809) rather than 19041 (20H1), and compiled demos/samples. In my non-thorough test, it seems those example exe files run well in Windows 10 LTSC 2019 with dark mode enabled. The only different behavior compared to 20H1, is that, title bar is black in 20H1 while in LTSC 2019 it is white.
Is there any potential risk or bug of doing this? If not, why didn't you just check against 1809 in the code to make dark mode available for LTSC 2019?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25529)I didn't have such system to test with it, so I preferred to not enable support for using undocumented APIs on an OS version I couldn't test. If things work fine there, we could enable support for it under 10.0.17763 too — it's not like we have any less guarantees about these APIs working there than under later Windows versions (in both cases we have none).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chip Zhang
ChipZhang left a comment (wxWidgets/wxWidgets#25529)At least in my test (thought not very thorough), things works fine for LTSC 2019 (based on 1809, build 17763), except for the title bar color.
Perhaps someone else that has such Win10 versions may report more test results.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chip Zhang
ChipZhang left a comment (wxWidgets/wxWidgets#25529)I just noticed, with this patch applied, build the samples with -mconsole (force attach a console window), and run them in Win10 1809, it prints error message:
darkmode.cpp at line 426: 'DwmSetWindowAttribute(USE_IMMERSIVE_DARK_MODE)' failed with error 0x80070057
But the program actually works fine, both the functionality and dark theme work fine, despite this message.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chip Zhang
ChipZhang left a comment (wxWidgets/wxWidgets#25529)It seems DWMWA_USE_IMMERSIVE_DARK_MODE in darkmode.cpp is used to make title bar dark. As I said before, even with the version patch in OP, title bar is still light in 1809. Hence this error.
I further researched this issue, making title bar dark is actually possible in 1809.
The point is, DWMWA_USE_IMMERSIVE_DARK_MODE is 19 for 1809, but 20 for higher versions. As for higher versions, I don't know the exact version number, probably 20H1.
I set DWMWA_USE_IMMERSIVE_DARK_MODE to 19, and eventually the title bar become dark in 1809!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chip Zhang
ChipZhang left a comment (wxWidgets/wxWidgets#25529)To make title bar dark for both 1809 and higher, first set it 20, if failed, try again with 19.
In this code:
HRESULT hr = wxDarkModeModule::GetDwmSetWindowAttribute()
(
hwnd,
DWMWA_USE_IMMERSIVE_DARK_MODE,
&useDarkMode,
sizeof(useDarkMode)
);
if ( FAILED(hr) )
wxLogApiError("DwmSetWindowAttribute(USE_IMMERSIVE_DARK_MODE)", hr);Insert the follows between the two statements:
if ( FAILED(hr) ) { hr = wxDarkModeModule::GetDwmSetWindowAttribute() ( hwnd, 19, &useDarkMode, sizeof(useDarkMode) ); }
This this fix and the version fix in OP, title bar is dark for 1809 and higher win10.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chip Zhang
ChipZhang left a comment (wxWidgets/wxWidgets#25529)BTW, is there an easy way to use -mconsole to generate demos/sample exe for windows debug build, instead of default -mwindows. I am using ./configure and gcc mingw cross compile.
I think it is intuitive to have a console window for debug build, and no console window for release build.
Without a console window, I missed the error message in the previous post.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#25529)I believe that most Win32 dark-mode implementations are based on this https://github.com/ysc3839/win32-darkmode/blob/master/win32-darkmode/DarkMode.h (there are some changes in the delay_load branch). There are few checks for builds < 1836, e.g.: https://github.com/ysc3839/win32-darkmode/blob/cc26549b65b25d6f3168a80238792545bd401271/win32-darkmode/DarkMode.h#L116 or https://github.com/ysc3839/win32-darkmode/blob/cc26549b65b25d6f3168a80238792545bd401271/win32-darkmode/DarkMode.h#L207
I don't think turning console on when using Windows would be expected. On Windows, wxWidgets debug messages go to the system debug output via OutputDebugString() Win32 API. You should be able to see them in your IDE (e.g., MSVS does but Code::Blocks does not), or use a 3rd party tool such as DebugView. Not sure what happens when you add -mconsole to -DCMAKE_EXE_LINKER_FLAGS when calling CMake; AFAIK, CMake uses -mwindows when calling add_executable() with WIN32 (using Console instead Windows subsystem has a significant effect on C++ code with MSVC) .
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25529)@ChipZhang Please make a PR with your changes, this is getting less trivial than just a single comparison fix and I don't want to push the code I couldn't test. TIA!
Concerning -mconsole: no, this would be a bad idea for the reasons explained by PB, please just install DebugView++ and use it instead.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Steve Cornett
stevecor left a comment (wxWidgets/wxWidgets#25529)This issue can be closed. See #26494, which set Windows 10 1903 as the minimum supported version for dark mode.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.