AppImage/AppImageSpec

Define system integration data to use for registering MIME types

kossebau opened this issue · 3 comments

Some applications are handlers for certain MIME types which might not (yet) be part of the shared-mime-info database at least on most target systems.
So for proper system integration those MIME types should be registered with the system, so that the app from the appimage can as well be registered as handler for files of those MIME types.

The spec should define what data in what files could be added to the appdir, so that system integrators (like appimaged) know what to look for and what to use.

The typical GUI linux system uses shared-mime-info. Info about deploying custom extensions (per user) can be found here: https://www.freedesktop.org/wiki/Specifications/AddingMIMETutor/

So applications which deploy custom MIME types following the XDG/FHS/shared-mime-info would normally deploy one or more files to $PREFIX/usr/share/mime/packages and then expect the package installer to invoke update-mime-database so all the new and old separate data about MIME types is integrated in the actual system database.
So for a start with the spec, given that other parts are already picking up optionally files from the XDG/FHS layout, the idea could be to point out that if there are any *.xml files in the AppDir at usr/share/mime/packages, system integration tools with XDG-based systems are recommended to deploy those files to the proper user directory ($XDG_DATA_HOME/mime/packages) with some unique name as also needed for undeployment, and then run update-mime-database.

What do you think?

We are doing this already, but it should be officially documented/specified once we have implemented AppImageCommunity/libappimage#23 (comment).

References:

Oops,, pardon, I should have closer looked at the sources. Guess I failed as I grepped for mime/packages, while https://github.com/AppImage/libappimage/blob/master/src/libappimage/libappimage.c#L310 currently also copies xml files also from any other subfolders of mime, which might be not the correct thing to do, as for what I know own definitions should only be made available via the packages subfolder.

So the issue can be mainly reduced to what you said, documenting things in the spec officially :)

PRs welcome!