Need to create the custom mime type in the Linux Flutter App

I want to create the custom mime type in linux.

As per the research I have found the below commands which works fine when run in terminal directly.

Here is my command

 <?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared- 
 mime-info'>
    <mime-type type="application/x-foo">
        <comment>Demo App</comment>
        <glob pattern="*.foo"/>
        <icon name="x-foo"/>
    </mime-type>
</mime-info>


xdg-mime install --mode user x-foo.xml
xdg-icon-resource install --context mimetypes --size 48 --mode user --theme Adwaita x-  application-foo.png x-foo
update-mime-database ~/.local/share/mime
update-icon-caches ~/.local/share/icons`

So we tired that commands running in to flutter using Process.run which works fine in debug mode.

But when I try to create the release build of snapcraft then the same commands are not working. Could you please help with this if I am missing something or is there something I need to add in snapcraft.yaml or somewhere else?

Need to create the custom mime type in the Linux Flutter App.

@jamesh do you know if anyone has looked at adding new mimetypes at install time?

Last time we looked, I think it was put in the “too hard” basket, in the sense that it was difficult to support in a way that would be safe and not have confined apps override mime types from the system definitions.

I was kind of curious what Flatpak does here, and it looks like it does support installing sanitised mime type definitions:

https://github.com/flatpak/flatpak/blob/65bc369a9f7851cc1344d2a767b308050cd66fe3/common/flatpak-dir.c#L7323-L7423

The main things it does are:

  1. disallow <magic> based matches.
  2. Adds a weight=5 attribute to <glob> elements. This is lower priority than the default weight=50, so prevents them from overriding system provided mime info.

It doesn’t seem to do anything else, but I’m not sure whether that is intentional or not. If <magic> is considered dangerous, then <treemagic> seems similar. There also doesn’t seem to be anything to stop <root-XML> matches from overriding system mime types.

It doesn’t sanitise the <icon> or <generic-icon> elements, relying on the package specifying icon names that Flatpak lets them control.

Thinking about how we could apply this to snapd, I think we’d want to do something like this:

  1. Allow snaps to include files in $SNAP/meta/gui/mime/packages/*.xml including mime definitions.
  2. Add new code in wrappers/ that will check the snap for these files, and write sanitised versions of them to /var/lib/snapd/desktop/mime/packages, renamed to snap.${SNAP_INSTANCE_NAME}.${filename}.xml. The sanitisation would do the following:
    • Filter everything except for <mime-type> elements within the root <mime-info> element.
    • In <mime-type> elements, only allow <glob>, <comment>, <icon>, and <generic-icon>.
    • Force weight=5 on the <glob> element.
    • Require that the <icon> and <generic-icon> elements reference icons the snap can install via $SNAP/meta/gui/icons (as supported by the code in wrappers/icons.go).
  3. If any mime definitions have been installed or removed by the snap, call update-mime-database /var/lib/snapd/desktop/mime.

From the XDG shared mime spec, it will look for mime databased in $XDG_DATA_HOME and $XDG_DATA_DIRS, so we should be able to have a snapd-specific mime database that will be consulted alongside the user’s database and the main system one.