Icon-mime type associations
rgammon at real.com
Thu Sep 16 04:48:09 EEST 2004
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
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
... 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:
<glob pattern="*.foo" />
... 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
... 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?
rgammon at real.com
Developer for Helix Player
More information about the xdg