Using an AppImage managed by AppImageLauncher as a launcher for datafile filetype

[wamcvey]

AppImageLauncher works great for launching an AppImage bundle and integrating that application in the desktop; however, I'd like to use an AppImage (in my case, PrusaSlicer) as a launcher itself for another filetype (.stl files). The integration that AppImageLauncher provides doesn't extend to associating an AppImage as a possible launcher to a different filetype as far as I know (at least under Gnome).

I see two potential ways to accomplish this. Figure out how gnome determines the set of possible Launchers and have AppImageLauncher add managed apps into that set. This way, PrusaSlicer would directly show up as an opener option when I go to associate an opener for stl files. Alternatively, I'd not mind simply using AppImageLauncher as the opener for the non-AppImage data files, and then AppImageLauncher can simply query the user "Open file type XYZ with one of these AppImages?" and it can tweak the invocation as appropriate.

Finally, thanks for providing such a useful tool!

[TheAssassin]

File associations are supported and work fine. There are some prominent examples like FreeCAD or Ultimaker Cura (which even supports STL files out of the box!) which demonstrate this.

File types are organized as MIME types on Linux desktops. Making your desktop recognize a file type and launch the right application depends on two steps. First, your desktop needs to recognize the file type. Therefore you need a so-called MIME type definition. That's an XML file that defines a few properties of the file type, most notably the name, as well as methods how to recognize such files. The simplest but also weakest option is to use file extensions. The by far more reliable way is to define some magic numbers (including their offset(s) in the file), so that when an application is interested in the MIME type of a file, it can check for those bytes' presence.

AppImages can ship MIME type definitions. libappimage, the foundation of the desktop integration which is internally also used by AppImageLauncher, copies those files into the right location upon integration.

So now that we have a proper way to detect the type of a file, we need to create a relation between application and MIME type which the desktop can use to associate an application as a "launcher", as you call it, for a certain file you intend to open e.g., in your file browser.

Pretty much any Linux desktop uses so-called Desktop Entries (better known as desktop files) to store relevant metadata about an application, e.g., the application's name and a description, the name of the executable (as well as parameters; this way you can also "inform" the desktop that it accepts files as parameters, which is essential in order to use any kind of "open with" functionality (just writing this here as it might be relevant for this and other similar issues)), names of icons etc.
There is a special key in the Desktop Entry Specification with which you can create the already mentioned association. You can define that a certain desktop file can handle one or more MIME types.

TL;DR: When there is a correct MimeType=... key in the AppImage's desktop file and the AppImage comes with a proper MIME type definition (or there is one present on the system already; just for completion), an application integrated through AppImageLauncher can be used to open files.

For the AppImage in question, Slicer PE (or nowadays PrusaSlicer), the AppImage doesn't come with either file. Therefore please open an upstream issue over at the PrusaSlicer repository! Please put a link to this issue there, it explains everything they have to do.

This is not an issue with AppImageLauncher, it's the AppImage that needs to be fixed, at least in my opinion.
There are other ideas, e.g., in #90, that request a way to customize the integration without having to touch the AppImage. While this might be possible, it would require a lot of effort from our side and you'd be the only one to benefit from the changes/fixes to the desktop file. In contrary to #90 in this issue it's especially noteworthy that the required changes would bring a huge UX improvement to any user of PrusaSlicer. I would personally benefit from this, therefore I took the time to write this detailed comment.

[wamcvey]

@TheAssassin Thanks so much for the detailed reply. I'll post the feature request on PrusaSlicer and will link to this thread (and update this thread with the link to the new issue).

[TheAssassin]

Considering this one as resolved.

[adrianinsaval]

does appimagelauncher install icons for mimetypes or just icons for an appimage?