Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define system integration data to use for registering MIME types #22

Open
kossebau opened this issue Jan 2, 2019 · 3 comments
Open

Comments

@kossebau
Copy link
Contributor

kossebau commented Jan 2, 2019

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?

@kossebau
Copy link
Contributor Author

kossebau commented Jan 2, 2019

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 :)

@TheAssassin
Copy link
Member

PRs welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants