AppImage - A suggestion on Desktop Integration

[Hendrik_Louw]

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

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}/somefile.properties
${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 application.properties 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 application.properties 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.

[probono]

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.

[Vadim_Peretokin]

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

[opsaaaaa]

im new to Appimage, i use lmms-beta witch comes as a .Appimage you can install older versions with apt install but the tools in the beta are just better.

All I want is lmms to have a launcher. i just want an easy one line command that handles all the details for me.

as an end user i dont care that appimages can run anywhere as many articles have pointed out. however i do care that it can’t run from the one place i want it to, the one place i start all of my other applications from.
having the option to put it anywhere is fine. making the end user think about where a good place to put it is a drag. especial when they are completely unfamiliar with it.

As far as Appimaged gose. i download it and run it and complains at me. “SOURCE is missing”. for a end user this is unacceptable. im sure i could find a solution after some digging but the fact that i have to means that it sucks for end users.

mayddbe Appimaged works great. i wouldn’t know.

complicated install prepossesses can be accepted when your target audience is developers but your average Joe needs it to be as simple as possible otherwise they wont bother.

[probono]

@opsaaaaa

As far as Appimaged gose. i download it and run it and complains at me. “SOURCE is missing”.

Are you sure you are not confusing the AppImage daemon appimaged (for users) with the AppImage creation tool appimagetool (for developers)?

@opsaaaaa

complicated install prepossesses can be accepted when your target audience is developers but your average Joe needs it to be as simple as possible otherwise they wont bother.

This is why we started the AppImage project…

[Royi]

I would suggest that AppImage would target use case which is similar to PortableApps.

I’m new to Linux and I am looking for is experience similar to what I had with PortableApps on Windows.
This experience idea is completely disconnect the application from the OS - “Leave No Trails”.
If I freeze system at one point, then run PortableApplication, close it and compare the system to what it was before running it, they are exactly the same!

This will give AppImage use case which will differentiate it from FlatPak and Snap.

Since you support cases where the AppImage will use local storage for Configuration Files (See https://github.com/AppImage/AppImageKit#special-directories) by defining .home and .config in the same folder the AppImage resides you practically almost there.

What’s needed is to build a menu system similar to PortableApps and that’s it.
Pay attnetion that the whole idea is that the menu system is also a Portable Application by itself.
Namely it can’t be a Daemon or System Wide installed application.
It should application which runs and leaves no trail behind it as well once it is closed.

[probono]

@Royi

I’m new to Linux and I am looking for is experience similar to what I had with PortableApps on Windows.
This experience idea is completely disconnect the application from the OS - “Leave No Trails”.

That’s what AppImage is for…

@Royi

What’s needed is to build a menu system similar to PortableApps and that’s it.

Why have another menu system and not use the system’s menu (like appimaged does)?

And you are aware that you can just double-click the AppImage files themselves, no need for a menu at all (like on the Mac)?

[Royi]

I really think the model should be PortableApps and not macOS’s app files.
I will explain why.

Because think of prgorams whcih interacts with other packages.
Think of TeXStudio + MiKTeX, JavaApplication + Java Run Time, Firefox + Firefox Plugin’s, GIMP + GIMP Plug Ins’, etc…

The way I see it, I’d like all of that to come in AppImage format and some governor AppImage to make order of all that with no OS interaction (Besides, on user request Start Menu integration and MIME registration).
The governors runs as regular program with System Tray icon initiated by user demand (Who can close it by Right Click on the System Try icon and choose close).

This will give use case for AppImage which can’t be replicated by FlatPak / Snap.

[probono]

@Royi

I really think the model should be PortableApps and not macOS’s app files.

My role model (roughly) is generally how things work on the Mac. I am not a (voluntary) Windows user but if you have good arguments for specific functionality that you think is better on Windows then we will of course consider it.

@Royi

Because think of prgorams whcih interacts with other packages.
Think of TeXStudio + MiKTeX, JavaApplication + Java Run Time, Firefox + Firefox Plugin’s, GIMP + GIMP Plug Ins’, etc…

The AppImage mantra is “one app = one file”. Which means that if an application requires a Java runtime (and we cannot safely assume that a suitable Java runtime is available on all target systems by default - which we can’t), then the AppImage for that application needs to ship the Java runtime as part of the AppImage. This is, by the way, what applications like the Arduino IDE are doing anyways, also for the Mac. Only by following this concept, we can be sure that an AppImage will run on the target systems without needing the user to download additional things. Which is our desired user experience.

Plug-ins are different. An application does not require plug-ins, but plug-ins merely enhance the features of an application. Hence they don’t have to be bundled inside the application, but the application can choose to load them from wherever the application likes (typically, from somewhere inside $HOME). This, together with the .home feature of AppImage, should allow you to use plug-ins in a portable way. That being said, there are some AppImages (e.g., the GIMP one) that ship with tons of plug-ins as part of the AppImage.

@Royi

The way I see it, I’d like all of that to come in AppImage format and some governor AppImage to make order of all that with no OS interaction (Besides, on user request Start Menu integration and MIME registration).
The governors runs as regular program with System Tray icon initiated by user demand (Who can close it by Right Click on the System Try icon and choose close).

appimaged basically is what you describe, but it does not have a “system tray icon” (I don’t like them and every Linux desktop environment calls them differently and implements them differently).

[Royi]

@probono

@Royi

The way I see it, I’d like all of that to come in AppImage format and some governor AppImage to make order of all that with no OS interaction (Besides, on user request Start Menu integration and MIME registration).
The governors runs as regular program with System Tray icon initiated by user demand (Who can close it by Right Click on the System Try icon and choose close).

appimaged basically is what you describe, but it does not have a “system tray icon” (I don’t like them and every Linux desktop environment calls them differently and implements them differently).

The user needs a way to interact with it.
Don’t like System Tray (Which is by far the best choice), try other ideas:

1. Settings File (Like the settings files of VS Code / Sublime Text).
2. Web Access (Something like in SyncThing).

[probono]

Not sure they are better. My question is, why have any sort of GUI for something that should need no interaction with the user and has no user-configurable settings.

[Royi]

@probono

@Royi

I didn’t mean replicate being a Daemon which is wrong in my opinion.

Well the thing that you want (something in the “system tray”) is basically appimaged with a tiny GUI to manually launch and to stop it, and to set the watched directories (the directory in which it itself resides being the default). Correct?

I will answer here and I think we should continue only here.

First step and the most important one is indeed System Tray to allow easy stop of the process / program.
Moreover, I think there are settings which should be user controlled:

1. User controlled ability (Per Application) to register on System Menu.
2. User controlled ability (Per Application) to register MIME.
3. User controlled ability (Per Application) to mark it as Executable.
4. User controlled ability (Per Application) to run using Sand Boxing (With AppImage which wasn’t marked as executable only being run within Sand Box).
5. User controlled ability to select the directories to scan (The default can as now, but let the user chose).
6. Use Portable Mode - namely it will create .home and .config. for the AppImage it finds automatically.
7. System tray to have easy access to those settings and ability to start and stop the program.

[probono]

In the meantime, if you just want to manually start and stop appimaged without it running in the background:

wget "https://github.com/AppImage/appimaged/releases/download/continuous/appimaged-x86_64.AppImage"
chmod a+x appimaged-x86_64.AppImage
./appimaged-x86_64.AppImage --appimage-extract
squashfs-root/usr/bin/appimaged # Launch it
# Press Ctrl-D to stop it

Writing a tiny GUI around it (“system tray icon”) shouldn’t be too hard.

[cgarry]

@Royi

5. User controlled ability to select the directories to scan (The default can as now, but let the user chose).

I really like this option as I want a single specific directory for all my AppImages that I choose to use. I specifically want to exclude the ‘Downloads’ directory so all downloaded AppImages do not automatically get execute permissions and added to the desktop menu.