# AppImage - A suggestion on Desktop Integration

**URL:** <https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150>\
**Category:** Developers\
**Created:** [February 16, 2017, 8:33am UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150 "2017-02-16T08:33:18Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hendrik\_Louw](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Hendrik\_Louw](https://discourse.appimage.org/u/Hendrik_Louw)\
**Post date:** [February 16, 2017, 8:33am UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/1 "2017-02-16T08:33:18Z")

</div>

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.

```auto
${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.

- **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

```auto
${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.

```auto
# 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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [February 16, 2017, 8:12pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/2 "2017-02-16T20:12:20Z")

</div>

Hi @Hendrik_Louw, thanks for your suggestions. Have you tried [appimaged](https://github.com/probonopd/AppImageKit#appimaged-usage) 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.

---

<div class="post-metadata">

**Author:** ![Vadim\_Peretokin](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/vadim_peretokin/32/48_2.png) [@Vadim\_Peretokin](https://discourse.appimage.org/u/Vadim_Peretokin)\
**Post date:** [March 7, 2017, 9:50pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/3 "2017-03-07T21:50:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![opsaaaaa](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/opsaaaaa/32/148_2.png) [@opsaaaaa](https://discourse.appimage.org/u/opsaaaaa)\
**Post date:** [May 25, 2018, 5:39pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/4 "2018-05-25T17:39:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 26, 2018, 6:31pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/5 "2018-05-26T18:31:01Z")

</div>

> [@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…

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 28, 2018, 6:52pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/6 "2018-05-28T18:52:12Z")

</div>

I would suggest that AppImage would target use case which is similar to [PortableApps](https://portableapps.com/).

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](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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 30, 2018, 5:44am UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/7 "2018-05-30T05:44:20Z")

</div>

> [@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)?

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 30, 2018, 6:06am UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/8 "2018-05-30T06:06:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 30, 2018, 6:25am UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/9 "2018-05-30T06:25:27Z")

</div>

> [@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).

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 30, 2018, 7:19am UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/10 "2018-05-30T07:19:52Z")

</div>

> [@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](https://syncthing.net/)).

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 30, 2018, 3:19pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/11 "2018-05-30T15:19:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 30, 2018, 3:53pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/12 "2018-05-30T15:53:10Z")

</div>

> [@LinuxPA, Linux Portable Apps Launcher](https://discourse.appimage.org/t/linuxpa-linux-portable-apps-launcher/184/9):
>
> > [@LinuxPA, Linux Portable Apps Launcher](https://discourse.appimage.org/t/linuxpa-linux-portable-apps-launcher/184/8):
> >
> > 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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 31, 2018, 5:10pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/13 "2018-05-31T17:10:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cgarry](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/cgarry/32/114_2.png) [@cgarry](https://discourse.appimage.org/u/cgarry)\
**Post date:** [May 31, 2018, 6:09pm UTC](https://discourse.appimage.org/t/appimage-a-suggestion-on-desktop-integration/150/14 "2018-05-31T18:09:05Z")

</div>

> [@Royi](#):
>
> 1. 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.