Icon-mime type associations

[Ryan Gammon]

Hi all,

I'm a developer on the Helix Player for Linux, and the RealPlayer 10 for 
Linux, which is based on the RealPlayer.

I'm involved in ensuring that the player follows the standards put 
forward by freedesktop.org.

We're very excitied to see some unification taking place between the 
gnome, kde, and other desktops in terms of how they deal with mime 
types. There is, however, one area of the spec in which we're running 
into problems.

The current specs don't appear to provide for an app to add an icon for 
a given mime type.

In the old .keys-based gnome system, we would add the mime type in 
question to our realplay.keys file that would look something like

audio/x-pn-realaudio:
        description=RealPlayer Presentation
        icon_filename=realplay-audio-ra.png
        ....

... and gnome-vfs would turn around and use this to associate 
audio/x-pn-realaudio with realplay-audio-ra.png (in theory, in practice 
the way keys files get merged together made this a little more 
complicated -- http://bugzilla.gnome.org/show_bug.cgi?id=106868).

There was one fundamental problem with the way gnome-vfs did this. Some 
types, eg audio/mp3, were set up in /usr/share/mime-info/gnome-vfs.keys 
to have default icons like gnome-mime-audio-x-mp3.png. If a .keys file 
wanted to, it was free to modify the icon_filename to something other 
than the gnome default.

In our case, we named our icons things like realplay-audio-ra.png in the 
interests of being desktop-agnostic, and so as not to collide with the 
gnome icon "namespace".

The problem here was that the icon theme stuff made the assumption that 
the icon filenames wouldn't change. When the icon name changed from 
gnome-XXX.png to realplay-XXX.png, suddenly RealPlayer icons started 
taking precedence over theme icons, as there was no "realplay-XXX.png" 
icon included in the theme.

The current spec indicated that we should create an xml file that 
replaces the .keys file for matching extensions and mime types. This xml 
file does not provide us with the ability to associate an icon with a 
mime type, as we used to be able to do with the keys file.

This means that if we want to include support for a mime type that's not 
in the master distro-provided list, we're unable to install an icon for 
that mime type.

One way to solve this would be to create the icon name programatically, 
instead of pulling it from something like gnome-vfs.keys, so if 
RealPlayer wanted to support a new .foo file format, we would add:

<mime-type type="audio/foo">
    <glob pattern="*.foo" />
</mime-type>

... to our realplay.xml, and "know" that the name desktops will come up 
with for this type will be mime-audio:foo.png.

The problem with this arises when more than one app wants to support 
audio/foo. There's no guarantee that a desktop will provide a 
mime-audio:foo.png, so 3rd party apps will in general want to provide 
one. If two apps support audio/foo, we have a filename collision.

Ideally, we'd like to see the icon lookup code:
- look for an appropriate document icon in the current icon theme under 
a standardized name
- if none is available, look to .desktop file for the default app for 
that mime type for a icon filename
- search icon themes & hicolor as ususal

One possible way to do this would be to add a line to the .desktop file 
like:

MimeType=audio/x-pn-real-audio
MimeIcon=realplay-audio-ra.png

... where the order of the mime types matches the order of the icons.

Some logic would also have to be added to gnome-vfs and the kde 
equivalent to do a .desktop file lookup for mime type icon names.

What do you folks think?

-- 
Ryan Gammon
rgammon at real.com
Developer for Helix Player
https://player.helixcommunity.org