SystemMenu is always light theme colored

[maj113]

Windows Terminal version

1.24.11911.0

Windows build number

29639.1000

Other Software

No response

Steps to reproduce

Right click the titlebar or alt + space will open the System Menu

Expected Behavior

The System Menu follows either windows color mode Dark/light preference or the Terminal Application Theme dark/light mode pref

Actual Behavior

It is always white/light

[NuWhE3wn0D]

It looks like the System Menu doesn't respect the theme settings based on user preferences. Could you check if the SetWindowTheme function is being called correctly for the System Menu component in the codebase? Additionally, ensure that the color settings are being updated with the ColorScheme class implementation. This might help in aligning the System Menu with the overall application theme.

[zadjii-msft]

I am CONFIDENT that this is already somewhere on the backlog but I can't find it

[zadjii-msft]

Okay well, if someone wanted to, they could try something like

terminal/src/cascadia/WindowsTerminal/IslandWindow.cpp

Lines 1841 to 1845 in a47fb5d

	void IslandWindow::UseDarkTheme(const bool v)
	{
	const BOOL attribute = v ? TRUE : FALSE;
	std::ignore = DwmSetWindowAttribute(GetHandle(), DWMWA_USE_IMMERSIVE_DARK_MODE, &attribute, sizeof(attribute));
	}

There's also the explorer dark theme hack, which we're not actually using in our code base anywhere, because we don't need to, because even though conhost is built in this codebase, the OS version of it internally just uses the private API.

It seems like both Explorer and Edge do use a dark themed version of it, so it is possible somehow.

HMENU hMenu = GetSystemTheme(_hwnd, ...);

---

wait here are more notes

https://github.com/lhecker/windows-dark-mode-switcher/blob/ee12ea41536fee4d34b89b4323cd8f67f5d2d8f2/src/main.c#L13-L18

https://gist.github.com/rounk-ctrl/b04e5622e30e0d62956870d5c22b7017

[maj113]

Could you check if the SetWindowTheme function is being called correctly for the System Menu component in the codebase?

I'll presume your comment is AI generated, since it is nonsensical, SystemMenu doesn't care about SetWindowTheme, it checks UxThemes app mode set by SetPreferredAppMode (Undoc and requires either dynamic import with GetProcAddr or a generated UxThemes.lib with ordinal 135 and 136 (FlushMenuThemes) for Flushing the UxTheme's process cache)

[maj113]

Okay well, if someone wanted to, they could try something like

terminal/src/cascadia/WindowsTerminal/IslandWindow.cpp

Lines 1841 to 1845 in a47fb5d

void IslandWindow::UseDarkTheme(const bool v)
{
const BOOL attribute = v ? TRUE : FALSE;
std::ignore = DwmSetWindowAttribute(GetHandle(), DWMWA_USE_IMMERSIVE_DARK_MODE, &attribute, sizeof(attribute));
}
There's also the explorer dark theme hack, which we're not actually using in our code base anywhere, because we don't need to, because even though conhost is built in this codebase, the OS version of it internally just uses the private API.

It seems like both Explorer and Edge do use a dark themed version of it, so it is possible somehow.

HMENU hMenu = GetSystemTheme(_hwnd, ...);

wait here are more notes

https://github.com/lhecker/windows-dark-mode-switcher/blob/ee12ea41536fee4d34b89b4323cd8f67f5d2d8f2/src/main.c#L13-L18

https://gist.github.com/rounk-ctrl/b04e5622e30e0d62956870d5c22b7017

UxTheme's internal functions are usually used for this, in my app where i implemented the dark mode system menu it is very simple, check if the theme bg is light or dark (terminal already has light/dark mode separation so this isn't required then map it to force light or force dark 2 or 3 value of SetPreferredAppMode then call the FlushMenuThemes to actually apply it:

forgive me for the assembly but it is more or less just this:

If flush is skipped it will successfully set the color only once but then after that SetPreferredAppMode wont have any effect so technically on startup it could be skipped and only flush on actual theme change

[DHowett]

Unfortunately, we're held to a bit of a higher standard as first-party Microsoft folks such that we cannot ship any private API uses in public code. Well, shouldn't. Not "can't" exactly.

[zadjii-msft]

So, yes TECHNICALLY calling that is easy.

But we (the Terminal Team) can't use Private APIs (like these) in our public OSS code for r e a s o n s.

Our two options are basically:

• help get these APIs documented as public APIs (or at least officially docupublic'ed APIs)
• add them to our private TerminalThemeHelpers library, and wrap them up for specifically our use case.

At this point the technical challenge is small. It's mostly a policy problem at this point.

(we had a long chat about this in team sync today, and we've got a mail thread on SetPreferredAppMode that we've started 😉)

[maj113]

So, yes TECHNICALLY calling that is easy.

But we (the Terminal Team) can't use Private APIs (like these) in our public OSS code for r e a s o n s.

I figured this would be the case and I completely understand, is there anything I could do to help get these APIs documented as you've already said?