AppImage - A suggestion on Desktop Integration


Hi All,
I’ve been reading up on AppImage and the work that Simon has been doing to automatically create desktop entries for downloaded AppImage applications and had some ideas on how we could make .AppImage files 1st class citizens of the linux desktop.

After an initial discussion with him via email, he suggested I publish my proposal here :slight_smile:

What I am proposing is a set of applications that will interact with each other via some messaging service (d-bus comes to mind) to provide a “natural” experience for app images on the linux desktop.

AppImage Control Center Daemon (AppImageCtrlD)

A daemon process started during system startup (systemd service) that will be responsible for controlling the applications which are considered installed in the system and will perform it’s functions by listening to messages received from the other applications.

The daemon will be responsible for maintaining a repository of applications installed in the system.
Suggested repository format is a simple disk structure.

${repo-base}/${Application Name}/${Application Version}/somefile.AppImage
${repo-base}/${Application Name}/${Application Version}/
${repo-base}/${Application Name}/${Application Version}/somefile.desktop
${repo-base}/${Application Name}/${Application Version}/somefile.launch-properties

Additionally, the daemon will maintaining two separate repositories, which we will refer to as the scope of the applications installation.

  • User - Scope for applications which are only installed for the current user. (~/.AppImage/repo)
  • System - Scope for application which are installed for the system (/usr/share/AppImage/repo)

The Daemon will provide the following services via its messaging framework.

  • List installed applications
    List all applications which are installed for the given set of scopes.

  • If no scopes are defined, it will assume both User & System as the scopes

  • List installed version of an application.
    List all versions of an application which is installed for the given set of scopes.

  • If no scopes are defined, it will assume both User & System as the scopes

  • Check application installation status
    Determines if an application is installed or not, optionally checking if a specific version is installed.

    • If the application is installed, but then the specific version, the latest installed version must be reported to the caller
  • Install an application
    Installs the application into the given scope

  • The message would contain a handle to an .AppImage file which must be installed

  • Will determine the application name & version from the following sources in order of priority

    1. An file inside the root of the squashFS filesystem of the .AppImage File
    2. from the filename of the application being installed using the pattern
${Application Name}.${Application Version}.AppImage
  • If no scope has been provided, assume the User scope.

  • Copies the .AppImage file to the correct location into the defined repository.

  • Creates a new .desktop file for the application into the defined repository that uses AppImgExec.

  • Copies the files for the application into the defined repository.

  • Creates a symlink of the .desktop file to expose it to the distributions menu.

  • Un-install an application (all versions / specific)
    Removes an application from the system by deleting it’s entries in the specific repo.

  • Update an installed application to the latest version.
    Uses AppImage Update tool to download the latest version of the application and then installs it as the latest version.

AppImage Integration Support (AppImageSupp)

A application which will provide support for .AppImage files in the system by registering a mime-type handler for all .AppImage files. When launched, the application will perform the the following steps.

  1. Call AppImageCtrlD and determine if the application with the given version is installed.
  2. If Application Not installed
    2.1 Prompt user that the application is not installed and ask if they would like to install or launch the application.
    2.2 Install the application if allowed, otherwise call AppImgExec to launch the application.
  3. If Application installed, but version is not installed
    3.1 Prompt user that another version is installed and ask if they would like to install this version or launch the latest installed version.
    3.2 Install the version if allowed or call AppImgExec to launch the latest version.
  4. If Application & version installed, launch the installed version of the application using AppImgExec

AppImage Launcher (AppImgExec)

Application which will launch a installed .AppImage applications.

# Usage: 
# ${Application Name}: The name the application is registered under in AppImageCtrlD
# ${Application Version}: The version of the application to launch. Optional and defaults to latest version.
# ${Additional Args}: Any additional arguments which must be passed to the application being launched.
AppImgExec ${Application Name} [${Application Version}] [${Additional Args}]

When launched, AppImgExec will perform the following.

  • Verify that application is installed in the repository.
  • Read the .launch-properties file for any arguments which must be passed to the application being launched.
  • mount the squashFS and execute the RunApp for the application.

AppImage Control Center GUI (AppImageCtrlUI)

Gui Application which allows the user to manage the installed applications
I’ve not fleshed out how this will work.


Hi @Hendrik_Louw, thanks for your suggestions. Have you tried appimaged and what do you think of it? It registers and unregisters AppImages with the system (e.g., shows them in the menus, etc.)

Do you know macOS .app bundles and .dmg files, and Launch Services? I would like to achieve the same level of “no (visible) management tools needed” user experience, where users can just drag-and-drop apps whereever they want, without needing extra tools. E.g., want to place an app on a USB stick? No problem, just copy 1 file there, works, done.


I agree. Introducing a whole another set of tools that the user has to worry about is not the way to go. KISS is.