fix(ui): key list-ctrl palette off actual background, not IsDark() (#274) - #276
Merged
Merged
Conversation
…mule-project#274) PR amule-project#179 keyed the theme-aware palette off wxSystemSettings::GetAppearance().IsDark(). On macOS + wxGTK that matches what the native wxListCtrl actually paints — dark mode propagates to the list background — so the light-tone palette is readable. On native Win32 (SysListView32) the story is different: even with AppsUseLightTheme=0, the list keeps its default white background, and light-tone text lands on it unreadable. Users see near-white search-result text on white background in the search tab (amule-project#274, Windows 11 dark mode). Fix: pick the palette from the list control's own background colour at draw time, not the OS appearance flag. On Linux/macOS the background follows the system theme so behaviour is unchanged; on Windows the list stays white so the (readable) light-mode palette is used regardless of the AppsUseLightTheme registry setting. When wxWidgets eventually gets full Win32 dark-mode wxListCtrl support (DWMWA_USE_IMMERSIVE_DARK_MODE etc.) the helper self-corrects: background turns dark, luminance test flips, dark-mode palette kicks in. Helper lives in MuleListCtrl.h next to the shared list-ctrl base; sites in SearchListCtrl.cpp + GenericClientListCtrl.cpp are the three call sites amule-project#179 introduced.
This was referenced Jul 2, 2026
Cflsft
pushed a commit
to Cflsft/amule
that referenced
this pull request
Jul 6, 2026
…mule-org#274) (amule-org#276) * fix(ui): key list-ctrl palette off actual background, not IsDark() (amule-org#274) PR amule-org#179 keyed the theme-aware palette off wxSystemSettings::GetAppearance().IsDark(). On macOS + wxGTK that matches what the native wxListCtrl actually paints — dark mode propagates to the list background — so the light-tone palette is readable. On native Win32 (SysListView32) the story is different: even with AppsUseLightTheme=0, the list keeps its default white background, and light-tone text lands on it unreadable. Users see near-white search-result text on white background in the search tab (amule-org#274, Windows 11 dark mode). Fix: pick the palette from the list control's own background colour at draw time, not the OS appearance flag. On Linux/macOS the background follows the system theme so behaviour is unchanged; on Windows the list stays white so the (readable) light-mode palette is used regardless of the AppsUseLightTheme registry setting. When wxWidgets eventually gets full Win32 dark-mode wxListCtrl support (DWMWA_USE_IMMERSIVE_DARK_MODE etc.) the helper self-corrects: background turns dark, luminance test flips, dark-mode palette kicks in. Helper lives in MuleListCtrl.h next to the shared list-ctrl base; sites in SearchListCtrl.cpp + GenericClientListCtrl.cpp are the three call sites amule-org#179 introduced. * clang-format: adjust pointer style in IsListBackgroundDark decl
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #274.
Bug
Windows 11 with dark mode enabled renders search-result rows as near-white text on a still-white list background. Regression from 3.0.0 → 3.0.1.
Root cause
PR #179 introduced hand-tuned per-theme palettes for
SearchListCtrlandGenericClientListCtrl, keyed offwxSystemSettings::GetAppearance().IsDark(). On Linux GTK and macOS the native list control adopts a dark background when the system theme is dark, so the light-tone palette IsDark() selects renders readably. On Windows, native Win32wxListCtrl(SysListView32) keeps its default white background even whenAppsUseLightTheme=0— proper dark-mode list-ctrl on Windows would needDWMWA_USE_IMMERSIVE_DARK_MODEplumbing wxWidgets doesn't currently do — so the light-tone palette lands on the still-white list, unreadable.Fix
Read the control's own background colour at draw time and pick the palette by its perceived luminance (ITU-R BT.601). Helper lives in
MuleListCtrl.h; the three call sites #179 introduced (one in SearchListCtrl.cpp, two in GenericClientListCtrl.cpp) become one-liner replacements.Cross-platform behaviour:
Forward-compatible: if wxWidgets eventually gains proper Windows dark-mode wxListCtrl support (or a downstream wraps it), the list bg turns dark and the luminance test flips back to the light-tone palette automatically.
Test
Built + installed on Windows 11 ARM64 (MSYS2 CLANGARM64), toggled
AppsUseLightTheme=0, ran a search: results now render readably instead of near-white-on-white. Also rebuilt on Linux ARM64 (Ubuntu, wxGTK 3.2.9): no visual regression, list still renders exactly as before.