Skip to content

feat(AppImage): amulegui launcher + shell shortcuts, fix em-dashes - #328

Merged
got3nks merged 2 commits into
amule-org:masterfrom
got3nks:feat/appimage-amulegui-integration
Jul 6, 2026
Merged

feat(AppImage): amulegui launcher + shell shortcuts, fix em-dashes#328
got3nks merged 2 commits into
amule-org:masterfrom
got3nks:feat/appimage-amulegui-integration

Conversation

@got3nks

@got3nks got3nks commented Jul 6, 2026

Copy link
Copy Markdown

Three related fixes bundled into one small PR while touching the AppImage first-run integration path:

1. amulegui as a first-class integrated launcher

Currently AppImageIntegration::PromptAndInstall writes only org.amule.aMule.desktop. Users can invoke amulegui by manually symlinking the AppImage under a amulegui-named path (AppRun's argv[0]-basename dispatch handles it), but the menu entry, dock icon, and MimeType handler association for amulegui are all missing.

Extended to also install org.amule.aMule.gui.desktop with Exec= pointing at ~/.local/bin/amulegui (see point 2), so a user picking amulegui as the ed2k:// scheme handler in Preferences (via #324) actually gets amulegui - previously xdg-open couldn't find the .gui .desktop and silently fell back to launching amule.

2. Shell command shortcuts

New InstallCommandSymlinks() iterates the AppRun-recognized names (amule, amuled, amulegui, amulecmd, amuleweb, amuleapi, ed2k, cas, wxcas, alc, alcc) and creates ~/.local/bin/<name> symlinks for each name the AppImage actually bundles. Users can now type amulecmd, amuled, etc. from any terminal without knowing the AppImage path - matches distro-package expectations.

Safety:

  • Refuses to clobber a pre-existing regular file at any of these paths (protects a distro-installed binary if one happens to live under ~/.local/bin).
  • Existing symlinks ARE replaced so a re-integration with a newer AppImage refreshes the target.
  • If ~/.local/bin isn't in PATH, the shortcuts still exist but only fire when the user types the full path - no worse than today's zero shortcuts.

3. Fix two user-visible em-dashes that mojibake on Windows

Same class of bug as #326 (already merged). My earlier regex-based sweep missed these because both em-dashes sit on multi-line C-string continuations, not the first line after _(:

  • src/AppImageIntegration.cpp:222 - the integration-prompt body
  • src/webapi/App.cpp:342 - amuleapi startup error when bound to a non-loopback address with no admin/guest password set

Both replaced with plain ASCII hyphens - identical rendering on Linux and macOS, no cp1252 decode mojibake on Windows.

Commits

  1. feat(AppImage): install amulegui launcher + shell shortcuts, fix em-dashes - the actual change (118 insertions across 2 files).
  2. po: regenerate catalogs after AppImageIntegration text changes - required by the App-catalogs-in-sync CI check.

Related

got3nks added 2 commits July 6, 2026 22:41
…ashes

Two related integration gaps + one string-encoding cleanup in the same
change:

1. amulegui first-class integration
   Previously the first-launch AppImage integration prompt only wrote
   org.amule.aMule.desktop (the monolithic amule variant). Users who
   invoked the AppImage via a `amulegui`-named symlink got amulegui
   running fine (AppRun's argv[0]-dispatch handled it), but no
   dedicated menu entry and no icon binding.

   Extended to also install org.amule.aMule.gui.desktop with Exec=
   pointing at ~/.local/bin/amulegui (the symlink from point 2 below),
   so AppRun's basename dispatch picks amulegui rather than the
   default amule. This also fixes the "amulegui registered as ed2k
   scheme handler opens amule" bug surfaced by amule-org#324:
   ProtocolHandlerManager writes the correct .desktop id to
   mimeapps.list, but xdg-mime couldn't find the .gui .desktop and
   silently fell back to amule.

2. Shell command shortcuts
   New InstallCommandSymlinks() iterates the AppRun-recognized names
   (amule, amuled, amulegui, amulecmd, amuleweb, amuleapi, ed2k, cas,
   wxcas, alc, alcc) and creates ~/.local/bin/<name> symlinks for
   each one the AppImage actually bundles. Users can now `amulecmd`,
   `amuled`, etc. straight from a terminal without knowing the
   AppImage path. Skips names that are pre-existing regular files
   (protects a user's distro-packaged binary if they somehow ended
   up under ~/.local/bin); replaces existing symlinks so a re-run
   with a newer AppImage refreshes the target.

3. Fix two user-visible em-dashes that mojibake on Windows
   Same class of bug as amule-org#326:
     - src/AppImageIntegration.cpp:222 (the integration prompt itself,
       reported by @got3nks during Ubuntu AppImage testing)
     - src/webapi/App.cpp:342 (amuleapi startup error when bound to a
       non-loopback address with no password set)
   Replaced the em-dashes with hyphens - identical rendering on Linux
   and macOS, no mojibake on Windows.

The integration prompt string is also expanded to mention
~/.local/bin so users know what's being touched.

Related: amule-project#324 (URL scheme handler PR that surfaced the amulegui gap).
Picks up the two revised msgids from the feat commit above:
  * the integration-prompt body (now mentions shell shortcuts and
    ~/.local/bin, and the em-dash was replaced with a hyphen)
  * the amuleapi startup-error message (em-dash → hyphen)
  * the log line summarising integration outcome (new %d counter for
    installed shell shortcuts)

Required by the App-catalogs-in-sync CI check per scripts/update-po.sh.
@got3nks
got3nks merged commit 60a3157 into amule-org:master Jul 6, 2026
10 of 12 checks passed
@got3nks
got3nks deleted the feat/appimage-amulegui-integration branch July 6, 2026 20:45
got3nks added a commit that referenced this pull request Jul 6, 2026
…WXGTK__ (#329)

Broke the master mingw-w64 build in #328: MinGW doesn't have lstat,
S_ISLNK, or symlink(2). The AppImage integration path is inherently
Linux-only - ShouldPrompt returns false on !__WXGTK__ so
InstallCommandSymlinks is never called on Windows / macOS - but the
symbols still had to link.

Wrap IsSymlink and the GTK body of InstallCommandSymlinks in
#ifdef __WXGTK__; provide a stub InstallCommandSymlinks on non-GTK
builds that returns 0, so the (dead) call site in PromptAndInstall
still links.

No behaviour change on Linux. Verified locally that macOS builds too.

Fixes the CI break from #328.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant