wxcas, alc: disable wxSizerFlags consistency checks at startup (#693) - #694
Merged
mrjimenez merged 1 commit intoMay 23, 2026
Merged
Conversation
wxWidgets 3.2 enforces strict assertions on redundant sizer-flag combinations (e.g. wxEXPAND + wxALIGN_CENTRE, wxEXPAND + wxALIGN_BOTTOM). Both wxCas and aLinkCreator's UI code use those combinations pervasively -- WxCasFrame and AlcFrame are full of wxSizerFlags().Expand().Center() / .CenterVertical() / .Bottom() Add calls. On distros that ship a wx build that aborts on the assertion (e.g. Fedora 43 / wx 3.2.8), both apps fail to launch with the "DO NOT PANIC" sizer assertion dialog (amule-project#693). amule already handles this in CamuleGuiBase::CamuleGuiBase (amule-gui.cpp:107) by calling wxSizerFlags::DisableConsistencyChecks() at construction, with a comment noting that the underlying flag uses should be cleaned up but the checks are post-3.0. Make wxcas and alc do the same so they're consistent with amule and unblocked for users on strict wx builds. The eventual cleanup of the flag combinations themselves remains a separate, larger sweep.
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
May 23, 2026
mrjimenez
pushed a commit
to mrjimenez/amule
that referenced
this pull request
Jul 30, 2026
…mule-project#694) `country_code` reaches the Web UI on /clients, /servers and their SSE diffs, but the flag image had nowhere to come from, so amule-project#690 could only paint the bare 2-letter code. This is the delivery mechanism for the artwork, and it adds no second copy of it: the famfamfam flags are already compiled into a byte table by src/icons/embed_icons.py for the desktop GUI, so amuleapi links the same generated `icon_data.c` and serves the flag_<cc> entries straight out of .rodata. Nothing touches the file system, so the route behaves identically in a source-tree dev run, an installed layout, and an API-only deployment with StaticRoot unset — and it has no path-traversal surface to guard beyond the code itself. `{code}` is two lowercase ASCII letters, or the literal `unknown` for the "??" placeholder CCountryFlags falls back to, so a frontend can match what the desktop list draws for an unresolved country. Anything else is a 404, including a well-formed code the set has no artwork for. The art id is built by concatenating "flag_" with the code, so that whitelist — not the upstream traversal gate — is what keeps a crafted code from naming a non-flag icon in the shared table. ETag, If-None-Match -> 304 and HEAD body-stripping come for free from the existing response post-processing; the handler only adds a one-day Cache-Control so a peer list full of <img> tags doesn't issue one conditional request per country on every reload. Responses whose media type is already entropy-coded (PNG, JPEG, GIF, WebP, woff/woff2, zip, gzip) now skip the gzip encoder. Deflate over a PNG buys nothing and routinely grows the body; before this the 700-900 byte flags cleared the 256-byte compression threshold and got encoded for no gain. Cost is ~320 KB of read-only data in the amuleapi binary — the whole icon table, of which only the flags are ever asked for. Trimming it to flags only would need a second embed_icons.py invocation and its own generated TU; the unused entries are pages that never fault in, which is not worth a parallel asset pipeline. Verified on macOS: all 249 files under src/icons/flags/ come back byte-identical over the route, and the new 32-country-flags regtest (29 assertions) covers content type, PNG magic, ETag/304, HEAD, the no-gzip guarantee, the "unknown" placeholder, malformed and traversal codes, 405 on non-safe methods, and that no auth is required.
ngosang
added a commit
to ngosang/amule
that referenced
this pull request
Jul 30, 2026
…mule-project#687) (amule-project#719) 1bc9d6e (amule-project#694) added GET /flags/{code}.png, but nothing consumed it: the country column of the peer list and of the ed2k server list still painted only the bare uppercase code, duplicating the same one-liner cell in two views. Both now render through a single new CountryCell in components.js: the 16x11 famfamfam flag from the route followed by the code, the layout the desktop lists already use. The image URL is built relative to window.location.pathname like BASE in api.js, so it survives a reverse-proxy subpath, and the route's one-day Cache-Control means a peer list full of <img> tags doesn't re-fetch a flag per country on reload. country_code is an empty string when the daemon's GeoIP is off or the IP doesn't resolve (amule-project#439, amule-project#440), so an empty code short-circuits to the dash the cell already showed -- no <img>, and in particular no request for the "/flags/.png" the route would 404. A well-formed code the flag set has no artwork for (zz, GeoIP pseudo-codes like ap/eu) also 404s, so onError hides the image and leaves the code readable instead of a broken-image icon. The cell gains a title with the localized country name via Intl.DisplayNames ({ type: "region" }) in the UI language, as docs/api/REFERENCE.md prescribes: no endpoint and no new translation keys, since the browser already has the data. The formatter is built once per module load, not once per row. Column width goes 52px -> 70px to fit flag + code + sort arrow; sortVal is unchanged, so the column still sorts by code. Verified against a live daemon: flags render in the Networks server list and the Clients list, an empty country_code shows the dash alone, /flags/zz.png falls back to the hidden image, the tooltip follows the EN/ES switch (France/Francia), sorting works both directions, and the console stays clean.
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
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.
Fixes #693.
Root cause
wxWidgets 3.2 enforces strict assertions on redundant sizer-flag combinations (
wxEXPAND + wxALIGN_CENTRE,wxEXPAND + wxALIGN_BOTTOM, etc.). BothwxCasandaLinkCreator's UI code use those combinations pervasively —WxCasFrameandAlcFrameare full ofwxSizerFlags().Expand().Center()/.CenterVertical()/.Bottom()Addcalls. On distros that ship a wx build that aborts on the assertion (Fedora 43 / wx 3.2.8 in the report), both apps fail to launch with the "DO NOT PANIC" sizer assertion dialog.Fix
amule itself already handles this in
CamuleGuiBase::CamuleGuiBase(amule-gui.cpp:107) by callingwxSizerFlags::DisableConsistencyChecks()at construction, with a comment noting the underlying flag uses should be cleaned up but the checks are post-3.0. Makewxcasandalcdo the same so they're consistent with amule and unblocked for users on strict wx builds. The eventual cleanup of the flag combinations themselves remains a separate, larger sweep.Test
Local macOS build of both
wxcasandalc(configured via-DBUILD_WXCAS=YES -DBUILD_ALC=YES) — clean. @cardpuncher's Fedora 43 case should now launch normally.