Re: Mime Type Analysis

[Maciej Stachowiak <mjs eazel com>]

Kurt Granroth <granroth kde org> writes:

> 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

Hi Kurt,

Thanks for writing this up! This document is super useful. I'm going
to use your info about the gnome-vfs MIME handling as the basis for
the docs on the mime format.

As I prelude, I'd like to mention that it's too late to majorly change
the MIME handling for GNOME 1.4, as we are pretty feature frozen and
the ship date approaches. However, we would like to do something nicer
for GNOME 2; we are not super happy with the current format. Basing it
on .desktop files might be nice, but there are some caveats. First,
let me fill in some missing info in your section on the gnome-vfs mime
handling; after that I will discuss steps towards having a common
solution.

> 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"

There's also the mime-magic file which stores the magic strings for
detecting mime types based on contents.

> .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???>

These are all indeed obsolete.

Also, the `default' fields arte going to go away, and the short_list
fields will be interpreted as priority sorted lists for which apps and
components should be preferred, based on availability on the system.

The short list fields are not just for Nautilus - they have three main
purposes in life.

1) Allowing a preference list for apps and components to handle
   various types, based on availibility; this means if the most
   preferred app for a type is not on the system, the next most
   preferred will be used, etc. This approach allows this to be done
   in a centralized way, as opposed to having each app specify it's
   own priority, which trusts all app authors to set an appropriate
   priority independently.

2) It provides a reduced list of applications for a mime type that can
   be displayed in an Open With menu by Nautilus or other apps. This
   means that if you have 100 text editors on your system, you won't
   by default get an unusable menu with all of them in it (although of
   course, which show up in the list is configurable by the user).

3) It allows specifying these things per user level; although right
   now only Nautilus uses user levels, this concept will become
   GNOME-wide in time.

> 
> 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.

gnome-vfs lets you peek inside some file types, like gzip'd files or
tar archives and treat them as mini file systems; this specifies the
method you can use to do that for a given file type.

> .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>

Here too we plan some changes, mainly to allow the name of the binary
to be specified separately from desired command-line arguments.



> 
> 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.

In principle this sounds like a good long-term solution (as I said,
it's too late to change all this for GNOME 1.4).

Looking at the description for how KDE does things, I have a few
specific concerns. The first few are technical issues with the
contents of the format:

* We like having application defaults and priority order per mime type
  kept centralized with the info about the mime type, rather than
  decentralized and kept with the info about the applications. This
  allows a consistent set of default applications to be carefully
  thought out, instead of trusting app authors not to fight over who
  gets a higher InitialPriority.

* We like having things per-user-level; it's likely that different
  defailt apps are appropriate to an expert vs. a novice.

* We like being able to specify the bonobo components desired for a
  given mime type (and I'm sure KDE likes having the same feature for
  KParts).

* It seems to me that there is value to specifying how to detect files
  as of a given mime type separate from describing the properties mime
  type (icon, apps, human-readable name). This needs to be doable both
  for extensions and for magic strings (perhaps we will want to keep
  the magic string aspects non-portable between the desktops...)

* Being able to specify a bunch of mime types in one file is appealing
  for people trying to create a system default.

The next few are semi-political issues arising from sharing this info:

* Each desktop needs to be able to specify preferred and default
  applications by itself. The last thing we need is huge political
  fights over whether gnumeric or KSpread is the default spreadsheet
  program. So these settings need to be per-desktop, not global.

* Each desktop may want to provide .desktop files for legacy
  applications that don't ship with them. We need to avoid having
  install conflicts when it happens (one way might be to have a
  project hosted by freedesktop.org that both KDE and GNOME people
  contribute to which is .desktop files for random apps that don't
  have them).


I'd like to find a way that we can address these concerns and still
have compatibility (most likely by using a .desktop-based
approach). Any ideas? One starting point I can think of is that each
desktop has it's own database of info about mime types installed in a
desktop-specific location (with fallback to the mime type database of
the other desktop if the mime type is not known natively), but
information about applications is shared and installed in a common
location, since the way that is stored is less likely to be
politically controversial. Just a starting point to kick off
discussion...


BTW, I was never involved in the original Desktop Entry Standard, but
I am the person who is responsible for the current incarnation of the
GNOME mime code, and most likely for future incarnations, so I think
you can trust my promise that anything we agree to here will be
implemented for GNOME 2.

 - Maciej