remove limitation on number of applications about type3-runtime HOT 4 OPEN

I'm not so sure if AppImage is the right format for this use case. After all, "one app = one file" is the core concept of AppImage.

We have had a few exceptional use cases with, as I think we called them, "multi binary AppImages", mostly for CLI tools as described in #4. @probonopd can you perhaps list a few examples?

I do see the use case, though. And most aspects important for the AppImage UX are also provided: Multi-binary AppImages also have zero external dependencies, and they can as well just be copied from A to B and run there then.

We would have to move away a bit from our core UX element. And there it gets tricky. AppImages must work without desktop integration. How to handle the "AppImage is double clicked" use case? It is surely more bloat to have two or three distinct AppImages, but at least everything's well specified there.

I think it's easier to, for GUI applications, bundle a sort of "toolbox" app that launches the others. Existing multi-binary AppImages do the same, e.g., by using an AppRun script to route the calls to the right tools.

For example, AppImageLauncher Lite's AppImage calls itself to start different services: ./AppImageLauncher-Lite*.AppImage appimagelauncherd.

from type3-runtime.

That's not what I'm discussing here - the expectation of a toolbox-like AppRun is there.
This is about the integration component - e.g in the DCSS example, one might want to launch the TUI version from the start menu.
That double-clicking has a default (e.g tiles) is a limitation, but much less of one than just only integrating a single variation.

from type3-runtime.

We could use some inspiration from LibreOffice, I guess.

LibreOffice has one core desktop file with the name LibreOffice which points to all the other applications. It additionally provides direct desktop files for all its applications.

All we have to do is define how additional desktop files in AppDir/usr/share/applications are handled during integration. Or, rather, we need a sort of "launch protocol" that defines how the auxiliary desktop files' Exec keys should be written. We could define it so that the name of the tool we want to launch is passed as a first positional parameter to the AppImage. Or we could use an environment variable.

from type3-runtime.

An AppImage must have one main entrypoint, which is executed when the ELF is double clicked.

GUI apps can do what LibreOffice does - present a menu when the app is started from which the user selects which of the different contained apps to run. It's not something the AppImage spec should be concerned with.

CLI tools can do what ImageMagick does. Let's not make things more complicated.

We don't want to water down the "one app = one file" paradigm. It is what makes AppImage so simple and joyful.

from type3-runtime.