icons, bundle: Linux hicolor PNG, Windows .rc icon, macOS amulegui.app - #464

Summary

Fixes the application icon on Linux and Windows (both amule and amulegui), and bundles amulegui as a proper .app on macOS:

1. Linux: install amule.png into the XDG hicolor theme, add StartupWMClass to amule.desktop, and share the icon with amulegui.desktop.
2. Windows: wire src/amule.rc (which already declared amule ICON "amule.ico") into the CMake build of the two GUI targets, so windres embeds the icon into amule.exe / amulegui.exe.
3. macOS: give amulegui the same MACOSX_BUNDLE setup the monolithic amule already has, producing aMuleGUI.app with the same .icns, plus the same ATS opt-out.

5 files changed, ~60 lines. Nothing in runtime code paths — only CMakeLists.txt / Makefile.am install rules, two .desktop entries, and one .rc file added to target_sources.

PR #337 proposed the Linux hicolor install but is narrower: it deletes amule.xpm and drops SetIcon(wxICON(aMule)). This PR is softer (keeps the XPM fallback and the in-code SetIcon) and additionally handles Windows and the macOS amulegui.

Before / after per platform

Linux (GTK 3 / GNOME / KDE)

Before: GNOME Shell's activity switcher / taskbar showed the generic cogwheel because:

• amule.png was in the repo but never installed anywhere.
• amule.desktop had no StartupWMClass, so GNOME couldn't match the running window (WM_CLASS=amule) to the .desktop file.
• amulegui.desktop referenced an Icon=amulegui that had no corresponding PNG anywhere on disk.

After: amule.png lands at /usr/share/icons/hicolor/128x128/apps/amule.png for both CMake and autotools make install. StartupWMClass=amule (lowercase — GTK derives WM_CLASS from the binary name via g_get_prgname(), which is the argv[0] basename, not wxApp::SetAppName()). amulegui.desktop now also Icon=amule, sharing the same visual identity (same choice we already made on macOS where both amule and amulegui use amule.icns).

The title-bar icon (via SetIcon(wxICON(aMule)) reading src/aMule.xpm at compile time) is unchanged — still works regardless of install.

Windows (MinGW / MSYS2, both x86_64 and ARM64)

Before: src/amule.rc existed with amule ICON "amule.ico" but was never referenced from CMakeLists.txt, so windres never compiled it into any .exe. The result: generic Windows icon in Explorer, in the title bar, and in the taskbar.

After: src/amule.rc is added to target_sources alongside version.rc for the two GUI executables (amule, amulegui). The .ico is now embedded in a .rsrc section (exes grow from 13 sections to 14). SetIcon(wxICON(aMule)) at src/amuleDlg.cpp:216 now also resolves on Windows (was already working on GTK via src/aMule.xpm).

The three console targets (amuled, amulecmd, ed2k) are intentionally left at just version.rc — they don't link wxWidgets GUI, so including amule.rc (which #include <wx/msw/wx.rc>) would fail at windres time with "wx/msw/wx.rc file not found".

macOS (wx 3.2+ on Homebrew)

Before: amule was already a proper .app bundle with amule.icns in Contents/Resources, but amulegui was built as a bare executable — no Dock icon, no proper menu bar, macOS treated it like a CLI tool.

After: amulegui gets the same APPLE block the monolithic target has:

• MACOSX_BUNDLE TRUE + MACOSX_BUNDLE_* metadata, identifier org.amule.aMuleGUI, bundle name aMuleGUI.
• amule.icns copied into aMuleGUI.app/Contents/Resources via MACOSX_PACKAGE_LOCATION.
• Same plutil -replace NSAppTransportSecurity POST_BUILD command (amulegui uses the same CHTTPDownloadThread / wxWebRequest path, so ATS opt-out applies equally).
• install(BUNDLE DESTINATION .) so cmake --install relocates the whole .app correctly.

Build / install instructions, with working icons

The PR's install rules put every icon asset in a standard XDG / bundle location. The .desktop files' Exec=amule %u / Exec=amulegui are relative, so they only work when amule{gui} is on PATH. The recipes below follow that contract.

Linux (Ubuntu / Debian / Fedora / Arch / openSUSE)

Most common: system-wide install to /usr/local.

cmake -B build -DBUILD_MONOLITHIC=YES -DBUILD_REMOTEGUI=YES
cmake --build build -j"$(nproc)"
sudo cmake --install build             # prefix defaults to /usr/local

/usr/local/bin is on PATH by default on every mainstream distro, so Exec=amule %u resolves. StartupWMClass=amule matches the running window and GNOME resolves Icon=amule against /usr/local/share/icons/hicolor/128x128/apps/amule.png.

User-level (no sudo) install to ~/.local: works the same, with one caveat — on Ubuntu with GDM, ~/.local/bin is not in the graphical session's PATH by default, which trips Gio.DesktopAppInfo's Exec= validation and hides the .desktop from GNOME Shell. Add it before logging in:

systemctl --user set-environment PATH="$HOME/.local/bin:$PATH"

Or use an absolute Exec= path in the installed .desktop if you just want to iterate locally.

macOS (Homebrew, wx 3.2+)

Monolithic GUI:

cmake -B build -DBUILD_MONOLITHIC=YES -DBUILD_REMOTEGUI=YES -DCMAKE_BUILD_TYPE=Release
cmake --build build -j"$(sysctl -n hw.ncpu)"

# Either run in place…
open build/src/aMule.app
open build/src/aMuleGUI.app

# …or install the bundles
cmake --install build --prefix /Applications

Both aMule.app and aMuleGUI.app now carry amule.icns in Contents/Resources, the same Dock icon, and the same ATS opt-out in Info.plist.

Windows (MSYS2 MINGW64 x86_64 or CLANGARM64 ARM64)

The icon embeds at build time. Configure + build + install produces a self-contained portable tree:

# In the MINGW64 (x86_64) or CLANGARM64 (ARM64) shell
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release \
    -DBUILD_MONOLITHIC=YES -DBUILD_REMOTEGUI=YES -DBUILD_DAEMON=YES \
    -DBUILD_AMULECMD=YES -DBUILD_ED2K=YES
cmake --build build -j"$(nproc)"

# Portable install — pulls in all MSYS2 DLLs via file(GET_RUNTIME_DEPENDENCIES)
# (already shipped in src/CMakeLists.txt for WIN32 AND MINGW), plus the CA
# bundle so libcurl HTTPS works outside the MSYS2 shell.
cmake --install build --prefix /c/Users/<you>/amule-portable

File Explorer, window title bar and taskbar now show the amule icon directly from the .exe resource section. The .ico resolution is fully local to the .exe — no additional install step, no registry tweaks.

Diff

 CMakeLists.txt     |  6 ++++++        ← install amule.png to hicolor
 Makefile.am        |  7 +++++++        ← same, for autotools
 amule.desktop      |  1 +              ← StartupWMClass=amule
 amulegui.desktop   |  2 +-             ← Icon=amulegui → Icon=amule
 src/CMakeLists.txt | 46 ++++++++++++++  ← amule.rc on WIN32 GUI targets;
                                          APPLE block for amulegui.app
 5 files changed, 59 insertions(+), 3 deletions(-)

No source changes, no ABI / runtime behaviour changes.

Risk / compatibility

• Linux: The legacy amule.xpm install under $(datadir)/pixmaps is kept — pure addition of the hicolor PNG. Packagers who already pull amule.png themselves (e.g. from their own packaging) keep working.
• Windows: Console targets (amuled, amulecmd, ed2k) intentionally do not get amule.rc — they would fail to compile it because they don't link wx (and amule.rc includes <wx/msw/wx.rc>). Only GUI executables get the icon, which matches the intent.
• macOS: amulegui as a .app changes the install output shape. The autotools path on macOS was never fully wired anyway, so in practice only users on the CMake path see the change — they gain a proper bundle.