aMuleGUI - Switching back from Dark mode on apps leaves grey elements

[ghysler]

When switching the Default app mode in Windows from Dark to Light, some elements are turned to grey.

Steps to reproduce:

Current settings
(Windows Settings -> Personalization -> Colors)
Choose your default Windows mode -> Dark
Choose your default app mode -> Light

Change default app mode to Dark, and back to Light again.
Switch to any other panel within aMuleGUI.
Every panel will now show grey elements that should be white instead.

aMuleGUI 3.0.1-520 on Windows 11 x64
aMuleD develop image 08/10 on Docker Linux 29.6.2

[got3nks]

Thanks for the precise repro, that made this quick to track down.

This one is in wxWidgets rather than aMule. On a live appearance change, wx replaces the window class background brush with a fixed colour, overwriting the colour index that Windows would otherwise resolve on every paint. Once that has happened the dynamic value is gone for good, and because it is a window-class property rather than a per-window one it applies to every window of that class, which is why it turns up across panels as you switch to them.

There is nothing set on aMule's side that causes it or could undo it. Restarting aMuleGUI after changing the Windows app mode clears it.

[ghysler]

Ok, clear. So this should be reported upstream?
I see there are currently 2k+ issues open in the wxWidgets repo, so the chances of this being a known issue are pretty high. Also I feel like I lack the technical know-how to properly report this in-depth.

For now I will just use the workaround of restarting aMuleGUI after the auto-switching to Light mode. Thanks.

[got3nks]

No need to report anything upstream — it is already known there, under a different description.

The mechanism is confirmed in wx source: on an appearance change wx overwrites the window class background brush with a fixed colour, replacing the colour index Windows would otherwise re-resolve on every paint (src/msw/window.cpp, whose own comment notes it assumes the sampled colour matches the original index). Because it is a class property it applies to every window of that class, hence the grey turning up across panels.

What made it sample the wrong colour is wxWidgets#26692: wx reacted to the change before wxMSWDarkMode::IsActive() had flipped, so it captured the pre-switch colour and then baked it in permanently. That was fixed upstream in mid-July, after the 3.3.3 release, so it is in master / the upcoming 3.3.4 and not in any released wx yet. Our Windows builds currently use wx 3.3.2.

We have not rebuilt against the fixed wx to confirm, so this is expected rather than verified — but it should resolve on its own once MSYS2 ships 3.3.4 and we pick it up. Your restart workaround is the right one until then.

Reopening to track that: we will re-run your repro after the wx bump and close this once it is confirmed gone.

[ghysler]

That is great news. We will see what happens once 3.3.4 is released and wired into aMule. Thanks for looking into this.

[ngosang]

Since WX takes a long of time to publish releases won't be interesting to try to build aMule with 3.3.x to see if the issues are fixed?

[got3nks]

On Windows and MacOS our builds are already on wx 3.3

The fix for this specific issue is not in any tagged release yet.