Project status
This project reads AppImage files and their desktop entries, and gives an AppImage a proper place on a GNOME desktop: a launcher in the application menu, icons in the hicolor theme, MIME associations, a context menu, and a window the owner can drive. It also keeps that integration honest afterwards — an AppImage can be inspected, refreshed, migrated from another tool, audited, and updated.
It started as a replacement for AppImageLauncher, which had been removed from this host.
Where that tool hid what it did, this one is built to be overt: plan prints
every file an install would write, explain prints where each fact came from,
and audit reports what disagrees with what.
Status
Complete. All five phases are done: the two format readers and the desktop locator, the
integration and the double-click handler, the migration of the launchers AppImageLauncher had
written and the update path, the published pages with a GitHub release and a one-command
install, and the prompt corpus re-synced with the project skeleton. Every requirement in
prompts/features/ now carries a stable identifier and every task names the
requirements it satisfies, checked by tests/09-prompt-contract.sh.
The launchers AppImageLauncher had written are migrated or gone, and an AppImage can be
updated: update --check asks the update information embedded in the file what the
vendor offers, update takes it, verifies the download, and keeps the file it
replaced. The same action is offered by the window's Update button and by the
launcher's context menu.
What remains in TODO.md is improvement rather than planned work: a retention rule
for the replaced file, a delta transfer when a zsync client is installed, and the version a
file name states. The integration itself is done and in daily use on this host.
The work is published. A GitHub release carries the built tools for Linux, and one script
installs them into ~/.local:
curl -fsSL https://raw.githubusercontent.com/pbannister/gnome-appimage-integration/master/scripts/install.sh | sh
The script checks the download against the release's SHA256SUMS before it
installs anything, and it leaves the *.AppImage handler alone: claiming that is a
deliberate second step, appimage-integrate handler install.
How it works
| Part | What it does |
|---|---|
appimage-inspect |
The container: the type 1 or type 2 layout, the ELF facts, the SquashFS payload, the
embedded desktop entry, the update information, and the .sha256_sig
signature. |
desktop-inspect |
The desktop: which entry wins an identifier, which icon a theme resolves, which application a MIME type opens, and why. |
appimage-integrate |
The integration: plan, install, uninstall,
list, refresh, migrate, update,
windows, audit, and the *.AppImage handler. |
appimage-activator |
The window a launcher, the handler, or the context menu opens: what the file is, what was discovered, what an action did, and the buttons that do it. |
Where the truth lives
The documents record what was verified against the specifications; the records record what each episode found, decided, and left open. The dashboard shows the live state of the host this project runs on, and AppImages lists what it has integrated there.
Nothing is written to the desktop without being asked for: every install can be reversed with
uninstall, which restores whatever launcher it displaced.