feat(gui): scalable SVG icons for toolbar and preferences on hi-DPI

[Zeyckler]

Summary

The main-toolbar buttons and the Preferences page-list icons were fixed-size raster art (32×32 / 16×16) embedded in the executable. Because the GUI is per-monitor-DPI aware, those bitmaps get drawn at their physical pixel size and look tiny/blurry on 4K and other hi-DPI displays. This migrates them to resolution-independent SVG, so wx rasterizes each icon crisply at whatever logical size / DPI the widget asks for.

On the artwork: these SVGs are a genuine best-effort redraw of the original pixel art. I'm a developer, not a graphic designer, so the goal was faithful, recognizable vectors that match the classic icons — not a visual redesign. They're deliberately kept as a clean, editable base (plain shapes/paths/gradients only) so a designer can refine or outright replace individual icons later without touching any of the plumbing — drop a better <name>.svg into src/icons/ and it's picked up automatically. Think of this PR as the infrastructure plus a solid first pass, not the final word on the visuals.

Pipeline

• embed_icons.py now embeds each icon's optional same-name .svg twin next to its PNG. AMuleIconEntry gains svg_data/svg_len. The PNG stays mandatory — it's the raster fallback and defines the icon's natural size — so an .svg with no matching .png is a build error.
• CamuleArtProvider::CreateBitmapBundle() serves an SVG-backed wxBitmapBundle via wxBitmapBundle::FromSVG() when wx has SVG support (wxHAS_SVG); otherwise (or if an SVG fails to parse) it falls back to the PNG plus a smooth 2× upscale.
• The main toolbar (Add_Skin_Icon) and the Preferences page list pull bundles from the art provider. An active user skin still takes precedence and keeps its own PNG art.
• CMake globs *.svg alongside *.png for the generated table; the checked-in icon_data.c fallback (used only when Python3 is absent at configure time) is regenerated to match.

Artwork

• 28 toolbar/preferences icons redrawn as flat, NanoSVG-compatible SVGs (shapes / paths / gradients only), plus an SVG for the IP2Country pin.
• Directories reuses the Crystal Project Tux; Events follows the eMule mascot.

Notes for reviewers

• Requires wx ≥ 3.2 (already the project minimum). NanoSVG is on by default in wx's CMake and autotools builds; without it, icons fall back to the embedded PNGs, so nothing breaks.
• The generic wxListCtrl on wxGTK/wxOSX only selects the hi-res rendition from wx 3.3; wxMSW uses it from 3.2. Toolbar (wxToolBar) benefits everywhere.
• Licensing check requested: the Tux is Crystal Project (LGPL, Everaldo); the mule follows the eMule project logo. Please confirm attribution/licensing suits the project before merge.

Test plan

• Validated all 29 SVGs are well-formed XML and use only the NanoSVG-supported subset (no text/filter/mask/clipPath/use/image/pattern/xlink).
• Rendered every icon at 16/32/48/64/96/128 px and on light + dark grounds, comparing each against its original bitmap; all read faithfully and stay crisp when scaled.
• Confirmed the checked-in icon_data.c fallback is byte-in-sync with the current .svg/.png set (29 SVG twins embedded).
• clang-format 18 clean on all touched C/C++.
• No local wxWidgets toolchain on the dev machine, so compile + runtime verification relies on CI (Ubuntu / macOS / mingw-w64), which builds wx with NanoSVG. Please confirm the icons render as expected on a hi-DPI display.

[got3nks]

Really nice work — the pipeline is clean, and the PNG-fallback + skin-precedence design plus the edge-case handling (UTF-8 write for mingw, clang-format off on the generated TU, malformed-SVG → PNG fallback) are all thoughtful. A few things before merge:

1. Reuse our existing locale-safe lowercasing. For the toolbar art-id fold in Add_Skin_Icon, we already handle the Turkish-İ case with an RAII helper — CCtypeAsciiScope (src/CCtypeAsciiScope.h). It's used in MaxMindDBDatabase.cpp to lowercase country codes into flag_<cc> art ids for this same CamuleArtProvider, so let's use it here rather than the hand-rolled loop:

#include "CCtypeAsciiScope.h"
...
CCtypeAsciiScope scope;
const wxString artName = iconName.Lower();

2. Licensing. Thanks for flagging it — the main thing to settle, and it's really just the two non-original icons: Directories (Crystal Project Tux, LGPL 2.1, © Everaldo) and Events (derived from the eMule mascot). Everything else is your own redraw and is fine.

For the LGPL Tux, a docs/THIRDPARTY.md entry alone isn't sufficient: aMule's About dialog already displays copyright notices at runtime, and LGPL 2.1 §6(c) then requires the icon set's copyright to appear among them — so it'd need both a THIRDPARTY.md entry (with the LGPL text, matching our picojson/muleunit entries) and a credit line in the About modal. The eMule-mascot icon is GPL-compatible (we're GPLv2+) but is more a branding/identity call for the team.

Simplest path: since the rest of the set is already your own art, replacing just those two — with original drawings (a generic folder / a generic events glyph) or CC0 / public-domain equivalents — avoids the attribution-in-app requirement entirely. We can go either way; the team should weigh in.

3. Screenshots. Could you attach before/after shots of the new toolbar + Preferences list on a hi-DPI display? The payoff is entirely visual and none of us has eyes on it yet, so it'd let the team review the artwork and agree on direction.

[got3nks]

One more minor point I should have included above — in CamuleArtProvider::CreateBitmapBundle's PNG-fallback path, when the requested size differs from the PNG's natural size the 2× rendition is built from the already-rescaled image rather than the original:

image = image.Scale(size, ...);          // natural -> requested size
wxImage image2x = image.Scale(2x, ...);  // 2x of the *rescaled* image

That's a scale-of-a-scale (two lossy resamples). Deriving the 2× from the original instead — natural.Scale(2 * size.w, 2 * size.h, wxIMAGE_QUALITY_HIGH) — keeps it a single resample and reads a bit crisper. It's fallback-only (no-SVG / NanoSVG-less builds) and only bites when the requested size differs from the 32²/16² natural art, so it's minor — but worth tightening while you're in there.

[got3nks]

Thanks for the quick turnaround on the review points! On the licensing though — the LGPL About-dialog credit you added is technically correct, but on reflection carrying a permanent in-app copyright notice (+ THIRDPARTY.md entry + license text) for a single icon feels disproportionate.

Since you've already hand-drawn the other 28 icons, the cleaner path is to do the same for the two derived ones:

1. Redraw Directories and Events as your own art (a generic folder / a generic events glyph). Then there's no third-party attribution at all and we can drop the AboutDialog.cpp + THIRDPARTY.md changes. This is our preference — and probably the least effort, since you're already drawing everything else.
2. Otherwise, if you'd rather reuse existing art, pick a CC0 / public-domain icon (no attribution required), or adopt a properly-licensed set wholesale where one documented third-party entry is justified — rather than a one-off LGPL glyph.

Either way keeps the app free of a per-icon copyright notice.

[got3nks]

All the review points are addressed — the CCtypeAsciiScope switch, the 2× rendition now derived from the original image, and the two derived icons redrawn as original art with the attribution dropped. Looks good.

I'm building on all platforms to verify, and I'll post screenshots here so the team can weigh in on the artwork. Thanks for the quick iterations!

[Zeyckler]

All the review points are addressed — the CCtypeAsciiScope switch, the 2× rendition now derived from the original image, and the two derived icons redrawn as original art with the attribution dropped. Looks good.

I'm building on all platforms to verify, and I'll post screenshots here so the team can weigh in on the artwork. Thanks for the quick iterations!

I'm adding more icons, as I forgot to rework several icons of the main window.

[got3nks]

I'm adding more icons, as I forgot to rework several icons of the main window.

OK, I tested on all platforms MacOS, Windows, Linux and they all render correctly.

Navigation bar:

Preferences panel:

Windows screenshots are taken with Display scaling at 175%.

@ngosang @danim7 @mrjimenez your feedback appreciated before we can merge this.

[got3nks]

Btw @Zeyckler, if you're comfortable working with SVG, we could use a hand updating the aMule logo as well.

I put together an SVG logo with SVGGenie AI

It's not perfect, but it could serve as a starting point.

[Zeyckler]

Here's how the icons look in a local build on a hi-DPI display (Windows, 4K @ 225% scaling), where the vector art is the whole point — everything is rasterized by wx at the display's scale instead of upscaling the old 16/32px bitmaps.

Main window — the toolbar glyphs (Disconnect, Networks, Searches, Downloads, Shared files, Messages, Statistics, Preferences, Import, About) plus the status-bar icons (info, users, up/down speed, and the composed eD2k/Kad connection globe):

Preferences — the page-list icons down the left side:

[Zeyckler]

Our comments crossed — the up/down arrows got exactly that treatment a few minutes before yours landed (057fc8b, comparison in my previous comment).

For users you were right, and it was mostly size: the old raster figure fills a 14×16 box at 66% pixel coverage, while the SVG bust was 10×13 at 37% — brighter per pixel but emitting about a third less light overall, which reads as "dimmer and smaller". e71b8ef scales the figure up to the same 14×16 footprint (with slightly broader shoulders, closer to the old proportions); emitted light now measures within 5% of the raster.

[Zeyckler]

Follow-up on the size half of your remark — the up/down glyph was indeed a touch smaller than the raster: the old arrowheads are 9px wide with 3px stems, the SVG had 8.6-unit heads and ~2-unit shafts. f2ebcf6 widens the heads to 9.2 and the shafts to 2.5 (+outline ≈ the old 3px stems); at 16px the glyph now covers 89px vs the raster's 74. Combined with the recolor:

[got3nks]

Good job, the users and up/down-speed glyphs both look great now.

The only thing I'd tweak is the connection-status arrows on the composite network glyph: making them a bit bigger would help it read more clearly at status-bar size.

[ngosang]

The globe icon is hard too see and IMHO it's packing too much information. Each arrow has 3 colora if I recall.

[got3nks]

The globe icon is hard too see and IMHO it's packing too much information. Each arrow has 3 colora if I recall.

It's always been 3 state for each network (Kad and ED2k):

• Red: disconnected
• Yellow: firewalled
• Green: OK

[Zeyckler]

I wasn't fully happy with how the parameterised tweaks to the previous arrow were converging, so I took your suggestion as an excuse to redraw the overlay arrows myself in an SVG editor — two bolder swoosh arrows cycling around the globe, tails toward the NE/SW corners, heads interlocking near the centre. They're substantially bigger than the previous rendition, which should help exactly where you flagged.

eb97d34 lands the redesign. Some plumbing worth noting: the editor placed the arrows via CSS transform-box/transform-origin, which browsers honour but NanoSVG ignores, so all transforms are baked into plain path coordinates; the SW arrow is the exact 180° point reflection of the NE one, both share the set's top-left-lit gradient, and the margins were balanced afterwards. All seven state overlays regenerate from the same geometry.

As always, a look on your dark GTK setup would be appreciated — happy to keep iterating if it still doesn't read right.

[got3nks]

The red arrows stand out well now. The green and yellow ones are still a bit harder to read, though — probably lower contrast against the globe. Could we try either a bolder outline on the arrows, or making them slightly bigger?

[Zeyckler]

a29e152 takes the outline route: every overlay arrow gets a bolder outline (0.4 → 0.6 units at 16px) and the green/yellow/orange outlines go darker, so the boundary does the work the hue can't — red keeps its color since that one already worked. On top of that the globe's rim is lightened a step, so the darkest edges in the icon now belong to the arrows rather than the border.

Bonus from the same session (fdc2838): the hand-drawn continent blobs got replaced with real coastlines extracted from a proper Earth-globe SVG, recolored to the icon's green.

Green / yellow / red pairs, before → after, dark and light bars:

Same request as always — a check on your dark setup would be great.

[Zeyckler]

@got3nks do you think it would be worthy to use the same globe (colors, shape, etc.) in the "Networks" and "Connection" (in settings)? So the 3 icons could share the globe part.

[got3nks]

Not sure, I'd probably keep them different

[got3nks]

Thanks for the contrast pass! Honestly, on macOS the connection-status arrows are still a bit hard to read for me. I think the most reliable fix is to make them a bit bigger — and we can give the glyph some extra horizontal space in the status bar to make room.

[Zeyckler]

Great timing — I'd just finished doing exactly that. aba924f enlarges the arrows substantially (I resized them by hand in the SVG editor, then normalized the pair): they now use practically the whole 16×16 box — a 14.8×14.8 isometric footprint with equal 0.3-unit margins, the SW arrow being the exact 180° reflection of the NE one.

Current (what you screenshotted) vs the enlarged version, green/yellow/red pairs on dark and light bars:

If macOS still wants more after this, I'm happy to take you up on the wider status-bar slot idea — with the SVG pipeline the glyph can render at any logical size, so widening the slot is purely a muuli layout tweak.

[got3nks]

Here's a side-by-side of the new SVG glyph vs the original PNG (left: SVG, right: original PNG):

The original's arrows are noticeably bolder and larger — I think we should size the SVG arrows up to match. You can see the difference clearly.

[Zeyckler]

Agreed — next to the original the arrows were still too light. 7ed6060 reworks them with substantially bigger chevron heads and shorter bodies (redrawn by hand again), normalized as usual: both arrows identical (the SW one is the exact 180° reflection of the NE one) and the pair balanced to an isometric 14.84×14.84 footprint with equal margins.

Original PNG vs the previous SVG vs the new one, on dark and light bars:

Hopefully this closes the gap on macOS — and the wider-slot option stays on the table if you'd like even more presence.

[got3nks]

@Zeyckler I took a pass at making the connection-globe arrows more readable at status-bar size — bolder solid arrows with big heads and a thin outline, a brighter green, offset into two lanes so they pass as an exchange (heads keep a gap), tails reaching the corners.

Consider it a starting point rather than a final design — feel free to refine it, tweak the shape/colours, or take it in a different direction entirely. I pushed it as a branch on my fork so you can pull it in and build on it:

git fetch https://github.com/got3nks/amule.git icons/conn-glyph-for-487
git cherry-pick 0e0cf0580

It's based on your current branch head, so it should apply cleanly. It touches only the eight status_conn_* overlays (base + ed2k/kad states) and their PNG twins, and regenerates icon_data.c via embed_icons.py.

Preview:

[Zeyckler]

@got3nks I don't like that straight arrow 😅 ; it loses the "curve" around the globe. IMHO, my design is more accurate to the original artwork, but as I said, I'm not a graphic designer, so I'm doing my best with AI and manual editing of the SVG in Boxy SVG Editor. Have you tried my last design on your Mac? Maybe it is enough for this first iteration of SVG migration.

[got3nks]

Yes I tested it on MacOS and it's still hard to read

[Zeyckler]

Yes I tested it on MacOS and it's still hard to read

Maybe it's a matter of making the arrows brighter more than the shape? I could also dull a little bit the globe to increase the contrast between them.

[got3nks]

That would help, but I’d also try to make their body bigger