Submit AppImage MIME Type to xdg/shared-mime-info

Hi,
do you have any plan about getting an "official" mimetype for .appimage files? Currently they are detected as executable files by the shared-mime-info database, which is fine. However there are use cases where a dedicated mimetype would be handy. For example, users of archiving tools like KDE's Ark or Gnome's file-roller may be interested in browsing the content of an appimage: https://bugs.kde.org/show_bug.cgi?id=363209

This new mimetype could inherit the application/x-executable mimetype, to express that appdata files are still executable files but they are also something more - e.g. they can be browsed with archiving tools.

Good point. Actually I have tried but never was successful; do you know why the following is not working?

<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
  <mime-type type="application/x-appimage; version=1.0">
    <sub-class-of type="application/x-executable"/>
    <sub-class-of type="application/x-iso9660-image"/>
    <comment>AppImage</comment>
    <magic priority="50">
       <match value="ELF" type="string" offset="1">
       <match value="CD001" type="string" offset="32769">
       <match value="AppImage" type="string" offset="32809"/>
    </magic>
    <magic priority="40">
       <match value="ELF" type="string" offset="1">
       <match value="CD001" type="string" offset="32769">
       <match value="APPIMAGE" type="string" offset="32809"/>
    </magic>
    <glob pattern="*.appimage"/>
    <glob pattern="*.AppImage"/>
  </mime-type>
</mime-info>

sudo xdg-mime install --mode system appimagekit-appimage.xml
xdg-mime query filetype '/home/me/Downloads/test'
# always returns:
# application/x-executable

@probonopd

@probonopd
Some of the <match> tags are not properly ended. You can check whether the installed XML is ok by running:

sudo update-mime-database /usr/share/mime

I was able to get the expected mimetype after fixing the above issues!

Strange. Changed it to

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
   <mime-type type="application/x-appimage; version=1.0">
      <sub-class-of type="application/x-executable" />
      <sub-class-of type="application/x-iso9660-image" />
      <comment>AppImage</comment>
      <magic priority="50">
         <match value="ELF" type="string" offset="1" />
         <match value="CD001" type="string" offset="32769" />
         <match value="AppImage" type="string" offset="32809" />
      </magic>
      <magic priority="40">
         <match value="ELF" type="string" offset="1" />
         <match value="CD001" type="string" offset="32769" />
         <match value="APPIMAGE" type="string" offset="32809" />
      </magic>
      <glob pattern="*.appimage" />
      <glob pattern="*.AppImage" />
   </mime-type>
</mime-info>

I get no more syntax complaints but it doesn't seem to work either. Ubuntu 16.04.

No idea, works for me (even your updated version). I'm on archlinux with shared-mime-info 1.6

Anyway, when you submit a new mime to upstream shared-mime-info, they require you to provide a test file as well, and that is what matters. If the test passes, the mime is gonna be accepted :)

Anyone, we need to iron this out and then submit together with a link to an example AppImage such as https://bintray.com/probono/AppImages/download_file?file_path=Leafpad-0.8.17-x86_64.AppImage according to https://cgit.freedesktop.org/xdg/shared-mime-info/tree/HACKING. I'm a bit lost here.

I can do it if you want, I recently submitted a mimetype so I have fresh memory of the burocracy :p

That would be great. Before you do please check that it works with and without the suffixes.

...and that the AppImage can still be executed by double-clicking when chmod a+x is set. Worst case would be that it is no longer recognized as an ELF executable in GNOME Nautilus and the likes.

Would making it a subclass of ISO automatically allow tools like Ark or file-roller to process it?

Would making it a subclass of ISO automatically allow tools like Ark or file-roller to process it?

Not necessarily. I can only speak for Ark, which unfortunately hardcodes the list of supported mimetypes

For whatever reason I had to log out and log in again and now it is working. AppImages still run when they have the executable bit set; however when the executable bit is not set they are tried to be opened with file-roller (which says it cannot handle the file). Is there a way around that?

Yeah, same here with Dolphin+Ark. I guess they are indeed detected as ISO by the file-managers.

What should be the expected behavior instead? Just nothing happening?

Another thing, the 2nd and 3rd magic offset are too big and I think the shared-mime-info maintainers will complain about this. Isn't enough to just match the ELF string?

Yeah, same here with Dolphin+Ark. I guess they are indeed detected as ISO by the file-managers. What should be the expected behavior instead? Just nothing happening?

When we don't subclass it to application/x-iso9660-image, then it doesn't try to open the AppImage with file-roller. GNOME then asks "There is no application installed for “AppImage” files. Do you want to search for an application to open this file?".

I am actually not sure which behavior is better. Just found out that when we subclass it to application/x-iso9660-image, then in GNOME I can right-click to open with gnome-disk-image-mounter which conveniently mounts the AppImage. Not bad... I guess we need to test the behavior under multiple *DEs.

@probonopd

@probonopd Not yet, I just pinged the freedesktop guy on the bugzilla ticket...

@probonopd

@probonopd Oh, that was quick. Please let me know what do you think about https://bugs.freedesktop.org/show_bug.cgi?id=100608#c4

Looks like you're suggesting vnd.appimage as the MIME type for v2. That doesn't sound like a great idea, since there are going to be future versions of the AppImage specification You should rather introduce some versioned type, e.g. appimage.type2.

The benefit of being able to distinguish between different types of AppImages for end user applications is so they can perform integrations like displaying the icon etc. which is a significantly different operation for different types of AppImages.

Could we not remove the type specific sub-class-of, add application/x-iso9660-appimage as an alias of the more generic application/vnd.appimage, and add the magic to the first type as well?

Type 1 uses ISO9660 whereas type 2 is an entirely different format. They are described in the AppImageSpec.

@TheAssassin

What about future versions of the spec (as pointed out by @TheAssassin)? Are we going to need a new mimetype every time?

Yes, but we are not foreseeing changes to the spec that would require a type 3 for a very long time, since the type 2 spec is quite generic.

@probonopd

@probonopd It's done! https://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=c643cab25b8a4ea17e73eae5bc318c840f0e3d4b

@elvisangelaccio

Thank you @elvisangelaccio.

@elvisangelaccio

Thanks @elvisangelaccio. I think I can close it safely now.

What does "vnd" mean?

Can we explain what is going on here?

@probonopd

@probonopd vnd seems to be used by the XDG folks for all "containerized" applications.

ZOMG. AppImages are not "containerized", are they?

Did you even bother looking this up on the Internet using a search engine?

https://www.startpage.com/do/dsearch?query=mime+vnd&cat=web&pl=opensearch

https://stackoverflow.com/questions/5351093/what-is-the-meaning-of-vnd-in-mime-types

vnd -> vendor specific

vnd indicates vendor-specific MIME types, which means they are MIME types that were introduced by corporate bodies rather than e.g. an Internet consortium.

Heh, so we are a "corporate body" now. Well, we are not an "Internet consortium" I guess.

Navigation Menu

Repository navigation

Submit AppImage MIME Type to xdg/shared-mime-info #144

68 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Submit AppImage MIME Type to xdg/shared-mime-info #144

Description

Activity

probonopd commented on May 18, 2016

elvisangelaccio commented on May 18, 2016

probonopd commented on May 18, 2016

elvisangelaccio commented on May 18, 2016

probonopd commented on May 18, 2016

elvisangelaccio commented on May 18, 2016

probonopd commented on May 18, 2016

probonopd commented on May 18, 2016

probonopd commented on May 18, 2016

elvisangelaccio commented on May 18, 2016

probonopd commented on May 18, 2016

elvisangelaccio commented on May 18, 2016

elvisangelaccio commented on May 18, 2016

probonopd commented on May 18, 2016

68 remaining items

elvisangelaccio commented on Jun 6, 2017

elvisangelaccio commented on Jun 6, 2017

TheAssassin commented on Jun 6, 2017

probonopd commented on Jun 6, 2017

elvisangelaccio commented on Jun 6, 2017

probonopd commented on Jun 6, 2017

elvisangelaccio commented on Sep 7, 2017

probonopd commented on Sep 8, 2017

TheAssassin commented on Nov 23, 2017

probonopd commented on Jul 19, 2018

TheAssassin commented on Jul 19, 2018

probonopd commented on Jul 19, 2018

TheAssassin commented on Jul 19, 2018

probonopd commented on Jul 19, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions