Idea

AppImageLauncher is supposed to serve as a kind of "entry point". Whenever an AppImage is executed (or even just double clicked, whether it's executable or not shouldn't matter), AppImageLauncher should be called instead, receiving the path to the actual binary as a commandline parameter.

There's a few options how to have the distribution call AppImageLauncher on all AppImages, and have it decide how to proceed:

• Use the binfmt_misc support in the Linux kernel to register AppImageLauncher as an "interpreter" for AppImage files

  • similar to how OpenJDK registers itself as an interpreter for executable JARs
  • example call: update-binfmts --package appimage --install appimage_type2 /usr/bin/AppImageLauncher --magic 'AI\x02' --offset 8
  • advantages:
    • it doesn't matter how the AppImage is called (Terminal, double click in file manager, call via desktop environments' launchers, ...)
  • disadvantages:
    • AppImages need to be made executable in order to use AppImageLauncher. If they are not, then binfmt_misc is not used

• Register an AppImage mimetype, and set up "Open with" functionality to have the system "open" AppImages with AppImageLauncher

  • add an entry to the global MIME type database (/usr/share/mime)
  • install AppImageLauncher as (the one and only) software that can open such files
    • by installing a desktop file with said MIME type
  • advantages:
    • works for non-executable AppImages
    • works on all major desktop environments
  • disadvantages:
    • executable AppImages will, when called, be called "normally", i.e., through the kernel
    • if another application claims support for the MIME type, then users might be able to open AppImages by default with the alternative application

Both methods have advantages and disadvantages. The most remarkable one is that they just work either for executable or non-executable AppImages.

In order to circumvent the lack of support for the opposite case is to combine both methods: Use binfmt_misc to open executable AppImages, and, as a fallback, have the MIME type ready. As binfmt_misc is most likely more robust, AppImageLauncher should mark all AppImages it sees executable when the user decides to run them, to have the system use the binfmt_misc method on further invocations.

The first versions will support AppImages of type 2 exclusively. The reason is it's by far more complicated to recognize type 1 AppImages, unless they have the magic bytes embedded (which is a SHALL but not a MUST, according to the AppImageSpec.