Making the Desktop Overt: Where Applications, Icons, and Parameters Come From

This document exists because AppImage integration is mysterious by default. Every fact a desktop uses has exactly one source file and a defined precedence. This document names the source and the command that reveals it.

Live-state facts were verified 2026-09-21 on this Ubuntu 24.04 GNOME Shell 46.0 host.

The Principle

The desktop never guesses. For every question it asks, a specification defines an ordered list of places to look and a rule for which answer wins.

question  ->  ordered sources  ->  first acceptable answer  ->  provenance

When something is wrong, the failure is almost always one of:

1. the fact is in a source the desktop does not read;
2. the fact is in a lower-precedence source that a higher one masks;
3. the fact points at a path or name that no longer resolves.

Each of those is discoverable with the commands below.

1. Where Applications Come From

GNOME reads desktop entries through GIO, whose search units are <data-dir>/applications, in this order:

Rules:

• The desktop file ID is the path relative to the data directory, with applications/ removed and / replaced by -.
• The first directory that yields an ID wins; a later file with the same ID is masked.
• The prefix-to-subdirectory mapping means kde-foo.desktop also matches <dir>/applications/kde/foo.desktop.
• A file outside an applications directory has no ID and is not discoverable by ID.

Reveal it:

2. Where the Parameters Come From

A launcher has exactly one source: its .desktop file. There is no hidden registry and no per-desktop override file.

What can make the effective value differ from the literal file:

Reveal it:

3. Where Icons Come From

Icon resolution follows the Icon Theme Specification.

The base directories are, in order:

1. $XDG_DATA_HOME/icons (default $HOME/.local/share/icons)
2. each $XDG_DATA_DIRS entry plus /icons
3. /usr/share/pixmaps

Within a base directory the lookup walks theme directories, then size directories, then contexts, then file names:

<base>/<theme>/<size>/<context>/<icon-name>.<extension>

• The preferred theme comes from the desktop settings, for example org.gnome.desktop.interface icon-theme.
• hicolor is the mandatory fallback theme and is always searched.
• A theme may declare Inherits= in its index.theme, which adds more themes to the chain.
• Size directories are named <N>x<N> or scalable.
• The apps context holds application icons; other contexts hold MIME types, devices, and so on.
• Extensions tried are .png, .svg, and .xpm.
• An Icon= value that is an absolute path skips all of this and is used directly.

Three failure modes are common and easy to see:

• The icon is installed in a directory that is not a valid size name, such as 0x0.
• The launcher uses an absolute path, so themes and scaling do not apply.
• The icon name in the entry does not match the installed file name.

Reveal it:

4. Where MIME Associations Come From

The default application for a MIME type is resolved from mimeapps.list files, highest priority first:

Rules:

• The group is [Default Applications], with lines mime/type=id1.desktop;id2.desktop;.
• The first resolvable desktop ID wins, falling through to the next file.
• [Removed Associations] subtracts IDs and [Added Associations] adds them.
• update-desktop-database writes mimeinfo.cache in each applications directory; it is a cache, not a source of truth.

Reveal it:

5. Where an AppImage’s Own Parameters Come From

An AppImage carries its own answers, and they can be read without running it.

Reveal it:

6. The Provenance Table

7. Worked Example on This Host

Verified 2026-09-21.

The AppImage MIME types were owned by appimagelauncher.desktop:

$ for m in application/vnd.appimage application/x-appimage application/x-iso9660-appimage; do
          printf '%-30s %s\n' "$m" "$(xdg-mime query default $m)"
      done
    application/vnd.appimage       appimagelauncher.desktop
    application/x-appimage         appimagelauncher.desktop
    application/x-iso9660-appimage appimagelauncher.desktop

The OrcaSlicer application had two active launchers and two backup files:

The two active entries disagree about both the icon and the window class, which is exactly the kind of hidden state this project is meant to surface.

Update 2026-09-21

AppImageLauncher was removed at the owner’s request; the AppImage MIME definitions it owned were first copied into $XDG_DATA_HOME/mime/packages/.

The AppImage MIME default is now appimage-activator.desktop, and desktop-inspect --mime reports $XDG_CONFIG_HOME/mimeapps.list as its source.

The appimagekit_* launchers it wrote remain, and appimage-integrate audit reports their now-broken /opt/appimagelauncher.AppDir/... context actions with the remedy “re-integrate the AppImage”.

8. The Audit

appimage-integrate audit applies the rules above to the real desktop and reports:

• duplicate launchers for one application;
• Exec targets that no longer exist or are not executable;
• Icon values that are absolute paths or that do not resolve;
• entries missing StartupWMClass, with the dock-icon consequence named;
• icon files installed in invalid size directories;
• the current default handler for each AppImage MIME type, and where that default is recorded.

Verification

• Search and precedence rules: verified 2026-09-21 against the XDG Base Directory Specification, the Icon Theme Specification, and the MIME Applications Specification.
• GIO application behavior: verified 2026-09-21 against GLib gdesktopappinfo.c.
• Observed host facts: verified 2026-09-21 by inspecting this host’s MIME configuration, application entries, and installed icons.