Consider to unify 4 tools into one

[probonopd]

Let's consider to unify 4 tools into one

• https://github.com/AppImage/appimaged
• https://github.com/azubieta/appimage-desktop-integration
• https://github.com/TheAssassin/AppImageLauncher
• https://github.com/CalebQ42/LinuxPA

In times in which people complain about fragmentation of the already small Desktop Linux user base, we should try not to add further fragmentation by offering 3 different ways to achieve desktop integration for AppImages.

As it stands now, not even I would be able to explain to a user which one to use, and why.

Hence I suggest we make a table that lists the differences, and then see if we can make one tool that either does it all, or at least can be configured to do either-or.

Aspect/feature	appimaged	AppImageLauncher	appimage-desktop-integration	For comparison: macOS LaunchServices
Triggered by	Watching directories with inotify	AppImages registered with binfmt	MimeType handler or Watching $HOME/Applications directory	.app extension
Put application into menu	Yes	Yes	Yes	No
Move AppImage file	No	Yes (asks user)	Yes (asks user)	No (suggests user to drag the .app into /Applications using the Finder)
Sandbox	Yes (if Firejail is present)	?	Not yet	No (warns if app is not signed)
Update	Adds update context menu item (if AppImageUpdate is present)	?	Not yet	No (apps can embed Sparkle framework)
Needs an app store/app center	No	?	No	No
Runs nicely alongside an app store/app center	Yes	Yes	Yes	Yes

Please add to the list (maybe we should move it to the wiki for better edit-ability).

[TheAssassin]

AppImageLauncher doesn't intercept calls to AppImages solely with binfmt-misc, but also the MIME type. It adds an update and remove desktop action to the desktop files. It ships with tools for this purpose, and doesn't depend on external tools (which need to have any specific filename). You can't break this functionality, like you can with appimaged, when the tool goes away.
Firejail support is planned (see TheAssassin/AppImageLauncher#32).

appimage-desktop-integration relies on the MIME type, and doesn't intercept calls. It has a different focus, it's more about "do you want to make this executable" instead of "do you want to integrate this AppImage in your system".

It should be noted that appimaged isn't scalable, and, compared to the other solutions, slows down the system e.g., during boot, and generates a lot of I/O operations (mainly read).

[probonopd]

The three are mutually exclusive (in the sense that no one ever will want to use all three), right?

[azubieta]

I don't think that the tools are mutually exclusive. They provide similar functionalities what differs are the workflows. So unifying the code base is possible and recommended. Additionally we could have a config tool to allow users to enable/disable things as they please.

[TheAssassin]

I think using them all together is pointless, though. But they're compatible. You could switch from appimaged to AppImageLauncher and vice versa. Brought to you by libappimage.

[probonopd]

These are two questions:

• Would anyone want to use all three together on the same machine, as of today?
• Can the three tools be merged (possibly by using runtime configuration options)?

[TheAssassin]

Why would you want to merge them? AppImageLauncher and appimaged work so differently. AppImageLauncher focuses on user control, not on automagic integration. There is no real point in merging appimaged and AppImageLauncher.

Using them together doesn't make much sense to me either. The update and removal tools AppImageLauncher provides are not compatible with what appimaged does. And AppImageLauncher is run only on behalf of a user action.

I don't see any point in merging them. Why don't you explain why you think it would be possible and make sense to merge any of them?

[azubieta]

In AppImage-Desktop-Integration ( ADI now on ), automatic integration is used along with the single app user control. So it's a merge between both approach. The rationale behind it is: I have several of apps in my system, the ones that I use every day are in $HOME/Applications and they are integrated in the system. The ones that I rarely use are somewhere else.

This allows automatic and unattended integration and removal of apps by means of the Applications directory. At the appimaged style, which keeps the idea making dead simple to integrate or remove an application in the system.

Also consider the AppImageLauncher is launcher functionalities useful, in the case of we would like to use Appimages from a CLI (where mime-types handlers are not used). Or to integrate/remove some applications that for some reason the user didn't want to have with the rest (by example in a Applications folder).

About the merge, we could provide from a single code base the three workflows:

• full $HOME folder monitoring
• only $HOME/Applications monitoring
• first run assistant (AppImageLauncher)
• update menu entry
• remove integration menu entry (which to be honest looks a bit awkward alongside with the delete menu entry)

[probonopd]

Why would you want to merge them?

AppImage is supposed to be simple, and having 3 tools doing kinda similar things (integrate AppImages into the desktop) is confusing - even me...

[TheAssassin]

AppImageLauncher keeps things simple from a user perspective. Much more simple than appimaged. Less magic, more control, and more visible actions. The user interface is kept really simple and understandable, but it has a lot of functionality in it.

[azubieta]

If simplicity means that the user have to do lees stuff to use a newly acquired application I must vote for appimaged (and it's magic which is totally transparent for the user). Once the application is download you can go and launch it from your menu or from the file.

IMHO The hard point about AppImageLauncher is control, the user can decide what is being integrated and what is not.

[TheAssassin]

Simplicity is more than just "count of mouse clicks". Simplicity involves the user experience, especially how understandable it is for the user. Nobody really understands appimaged. It does monitor only a set of predefined directories (which the user doesn't necessarily know), and doesn't work for applications on the entire system. If I'd plug in a USB drive with a set of AppImages, AppImages on then couldn't be run by the user if they weren't executable. And the user might not even want these to be integrated, not even for a minute.

Also, if AppImageLauncher crashes, the user will notice immediately, and can report the issue. If a daemon ever crashes, a user needs to spend time on investigating this when they want to launch an AppImage that they expect to be integrated.

Also AppImageLauncher is not prone to common daemon bugs like memleaks. It just runs during the launch, and then terminates. This is quite understandable. It works similar to a runtime.

[azubieta]

Actually end user doesn't want to understand anything about adding or removing applications from their systems. They just want to have an application or not.
The only thing that they should know: applications are stored at $HOME/Applications (or wherever you like)
Also it's true that there would be some applications that you are only testing and you don't want to integrate.
If the deamon crashes Apport (or something alike) will let you know to report the error.

Memleaks it's not a valid argument, it just says that we are not good C/C++ programmers.