Mime Type Analysis

[Kurt Granroth <granroth kde org>]

I did an analysis of the similarities and differences between the two
mime type systems in GNOME and KDE.  If there is any interest in this,
we need to start a productive discussion now
----------------------------------------------------------------------
Analysis of Mime Type Handling in GNOME and KDE

Kurt Granroth <granroth suse com>
Nov 30, 2000

Abstract
========
In order for KDE and GNOME applications to be treated the same by
users, certain subsystems within the two desktops need to be shared.
One of these is the Mime Type system.  Currently, while there is a
defined standard shared by GNOME and KDE concerning this, only one
desktop actually follows it.  This paper will attempt to define where
each project is at in regards to this issue and suggest some ways of
reconciling the differences.

Commonalities
=============
Both desktops use the concept of mime types to handle "file
associations".  Each mime type has certain properties associated with
it.  The major ones are:

o Name of mime type (e.g., text/plain)
o Extensions honored (e.g., .txt)
o Human readable name in various languages (e.g., Plain Text Document)
o Applications that handle type (e.g., kedit, emacs)
o Icon assocated with type
o Misc info

While the end result of getting this information is the same, the ways
the two desktops accomplish this are quite different.

There is also the concept of "magic" -- finding the type of a file by
examining the file contents.  Both KDE and GNOME handle this in a very
similar manner.  In any event, this information is never user
specified, so it is out of the scope of this paper.

The GNOME System
=================
This paper assumes that the GNOME VFS will take over all mime type
duties for future versions of GNOME.  There is little to no
documentation found for this, so all information here is gleaned
directly from the config files found in the GNOME CVS module gnome-vfs.

The mime type information is split up into three main files.  All
three files are found in $share/mime-info.  In typical fashion, the
default (system wide) ones are in $GNOMEDIR/share/mime-info and
user-modified ones are saved in $HOME/.gnome/share/mime-info.

It appears that there can be multiple versions of each file and the
files are merged together.  It's unclear whether individual
applications should ship their own versions of the files or if they
should just append to the existing version in the user's home
directory.

None of the files are documented beyond comments in the default files
themself.

The breakdown of the files is like so:

o Mime type listing and their extensions are stored in files ending with
  the ".mime" extension.  The system-wide file is called
  "gnome-vfs.mime"  These files are used to identify a file as a
  particular mime type.

o Mime type information like icons, human readable (and translated)
  descriptions, default applications, etc, are found in files ending
  in the ".keys" extension.  The system-wide file is called
  "gnome-vfs.keys"

o The information about applications that can handle mime types is
  found in files with the ".applications" extension.  This file
  contains information about the applications that are referenced in
  the .keys file.  The system-wide file is called
  "gnome-vfs.applications"

.mime files
-----------
The format is like so:

mime-type
    ext[,<priority>]: <list of extensions separated by spaces> 
    regex[,<priority>]: <regular expression matching filename>

The priority is optional (defaults to 1).  It is used whenever a
different mime type should take precedence.  The standard example uses
files with the .tar.gz extension.  This must be a priority 2 since
gzip takes precedence over tar.

.keys files
-----------
All mime types found in the .mime files are duplicated in this file.

The format of this file doesn't seem to be defined anywhere.  This is
what can be deduced from the default gnome-vfs.keys file:

mime-type
    description=<english human readable description>
    [<lang code>]description=<language specific description>
    default_action_type=[application|component]
    default_application_id=<application>
    short_list_application_ids_for_novice_user_level=<app list>
    short_list_application_ids_for_intermediate_user_level=<app list>
    short_list_application_ids_for_hacker_user_level=<app list>
    default_component_iid=<Bonobo component handler ID>
    short_list_component_iids_for_novice_user_level=<Bonobo component>
    short_list_component_iids_for_intermediate_user_level=<Bonobo component>
    short_list_component_iids_for_hacker_user_level=<Bonobo component>
    icon-filename=<name of icon>
    vfs-action=<vfs filter or handler??>
    open=<obsolete???>
    test=<obsolete???>
    compose=<obsolete???>
    copiousoutput=<obsolete???>

The applications listed in the 'application_id' fields are defined
later on in the ".applications" file.  The 'short_list' fields are
clearly intended for use in Nautilus.

The 'open', 'test', 'compose', and 'copiousoutput' keys seem to be
obsolete.  They may be a carry-over from the old "mailcap" files.

The 'vfs-action' key seems to be for those mime types that can be
handled directly by the VFS system and don't need an application or
component handler.

.applications files
-------------------
The format doesn't seem to be defined anywhere.  This is what can be
deduced from the default file:

application
  command=<command line name>
  name=<human readable name>
  can_open_multiple_files=[true|false]
  can_open_uris=[true|false]
  requires_terminal=[true|false]
  mime_types=<list of mimetypes separated by commas>

The KDE System
==============
The KDE system is mostly documented in the Desktop Entry Standard.
All mime type information is found in individual ".desktop" files.
The files are split into several directories:

o Information about the mime types themself are found in
  $share/mimelnk and subdirectories
o Information about applications that handle mime types are found in
  $share/applnk and subdirectories

Each mime type gets its own ".desktop" file.  The file placement and
naming depend on the type.  For instance, the file describing the mime
type "application/pdf" would be found in "$share/mimelnk/application/pdf.desktop".
These files contain the mime type name, the human readable
description, the extensions or regexps for identifying files, and the
icon associated with this mime type.

Each application also gets its own ".desktop" file.  The file
placement and naming is arbitrary in the sense that they don't change
the mime type handling.  These files are the same ones that the "K"
Menu picks up and displays.  These files contain information like
the executable name, translated and human readable name, mime types it
can handle, etc.

Each application ships at least one ".desktop" file that describes the
application and the mime types it handles.  If it handles new or
application-specific mime types, then it also will ship .desktop files
for each of the new types.

The entire format of these files can be found (at least) here:

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kio/DESKTOP_ENTRY_STANDARD

This paper will only describe the most commonly used keys.

Mime Type .desktop Files
------------------------
The format is like so:

[Desktop Entry]
Type=MimeType
MimeType=<mime type>
Comment=<English human readable description>
Comment[<lang code>]=<Translated human readable description>
Icon=<icon associated with this type>
Patterns=<list of regexps and extensions separated by semi-colons>

The 'Icon' field assumes that the icon has a .png or .xpm (in that
order) extension.

Application .desktop Files
--------------------------
The (abbreviated) format is like so:

[Desktop Entry]
Type=Application
Name=<English description>
Name[<lang code>]=<Translated description>
MimeType=<list of mime types separated by semi-colons>
InitialPreference=<a number>
Exec=<executable path>
Icon=<icon associated with this application>
Comment=<longer description of this application>
Comment[<lang code>]=<translated>

There are quite a few more fields, but they have little bearing on
this subject.

The InitialPreference field is somewhat arbitrary.  The .desktop file
with the highest InitialPreference for a given mime type will be the
default application.  This is user settable.

Conclusion
==========
The noble end-goal here would be to share the exact same method of
defining all this information.  As should be pretty obvious from this
brief analysis, there are a number of similarities between the two
systems.  Both systems contain all the necessary information to do the
job.  Each contains some extra information that is desktop specific
(e.g., Bonobo or Nautilus related for GNOME, KParts or MapNotify
related for KDE) but there was nothing in those fields that required
the given format of the files.

Neither system seems to have any technical advantage over the other.

What it comes down to is that neither KDE nor GNOME are tied to their
respective systems due to any technical reason.  All reasons are
historical, political, or arbitrary.

However, the fact remains that they are different enough that each
desktop cannot currently use the other desktop's system with code
additions.

Possible Solutions
==================
There are many possible solutions to this.  Here are some of the major
ones with pros and cons:

Solution: KDE standardizes on the GNOME system
  Pro(KDE): Goodwill garnered from "taking the first step"
  Con(KDE): Would require a *complete* rewrite of mime type handling
            as there is no code in KDE that can handle this system
  Pro(GNOME): Wouldn't have to change at all
  Con(GNOME): None

Solution: GNOME standardizes on the KDE system
  Pro(Overall): Both desktops would be honoring the already defined
                standard
  Pro(KDE): Wouldn't have to change at all
  Con(KDE): None
  Pro(GNOME): .desktop parsing code already exists in GNOME code
  Pro(GNOME): Goodwill garnered from "taking the first step"
  Con(GNOME): Would need to rewrite some internals

Solution: KDE honors GNOME system and GNOME honors KDE system
  Pro(Overall): Neither project will have "beat" the other
  Con(Overall): Both projects would have to add lots of code

Solution: Yet another standard is defined
  Pro(Overall): Neither project will have "beat" the other
  Con(Overall): Both projects would have to rewrite everything
  Con(Overall): It would take time to define an arbitrary standard

Personal Opinion
================
First, I'd like to make sure that my analysis is correct.  As I
mentioned, I couldn't find any documentation on the GNOME system, so
if I got it wrong, I'd like to know that.

I don't think that too many people would disagree that a standard way
of handling mime types would be A Good Thing that would benefit both
projects.  However, both projects currently have a "home-grown"
solution... and with the "Not Invented Here" (NIH) mentality prevalent
in both camps, making standards hasn't been the easiest job.

So I started this paper in the hopes that I could find where the two
systems are common.  Then, I thought, I could create Yet Another
Standard that would be similar enough to each to be familiar but
different enough so that neither camp could proclaim victory.

But something happened while researching this -- I found that there
already *was* a standard defined for mime types that was done jointly
by a KDE and GNOME reps.  It was done over a year ago and was agreed
on by both camps.  I'm referring to the Desktop Entry Standard.
The DES has an entire "chapter" on Mime Type handling.

If there is already a "standard", why, then, don't both projects
follow it?  I don't have an answer to this.  Perhaps the GNOME project
didn't want to change their system immediately and were going to wait
until 2.0 or VFS.. and when that time came, they had already forgotten
about the standard.  Or perhaps this section of the standard was never
communicated to the right people.  Or maybe it was added by the KDE
rep and never *really* agreed upon by the GNOME reps.

With this history, though, I am loath to start another standards
making process.  If the last one wasn't followed, there is little
guarantee that the next one will be.

So (HUGE personal opinion, here), I think the best bet would be for
the GNOME project to follow the agreed upon DES.  Now is a great time,
too, since the VFS layer still hasn't been released.  There is already
ample code in GNOME for handling .desktop files so that shouldn't be a
problem either.

I am open to ideas, though.  Am I way off base, here?  Discussion,
please!
-- 
Kurt Granroth            | http://www.granroth.org
KDE Developer/Evangelist | SuSE Labs Open Source Developer
granroth kde org         | granroth suse com
            KDE -- Conquer Your Desktop