Re: Important desktop-wide change (MIME)

[Christian Neumair <chris gnome-de org>]

Am Mittwoch, den 21.07.2004, 18:33 +0200 schrieb Sven Neumann:
> Hi,
> 
> Sean Middleditch <elanthis awesomeplay com> writes:
> 
> > We need something that makes it easy to update the database, doesn't
> > need modification of package-manager installed files (many systems don't
> > support that well at all), and can accurately reflect what MIME types a
> > given application can handle...
> > 
> > What about providing a method for running an external command to list
> > MIME types?  i.e., apps that have variable support MIME types (through
> > plugins, or whatever) could just offer a utility or command line option
> > to list them out, one per line, and the .desktop file could have an
> > entry like:
> > 
> > CheckMimeType=/usr/bin/myapp --list-mime
> > 
> > Packagers then just need to call the update-mime-database command after
> > their plugin is installed.
> 
> I like that idea. It would work perfectly for GIMP 2.2 since we
> changed our file plug-ins to register the MIME types they are able to
> handle. I would add a --list-mime command-line option if you decided
> to use it this way.

I absolutely dislike this proposal. How would the MIME system know that
the MIME list changed without crappy .desktop touching or newly
introduced notification complexity?
I've got a (hopefully) better proposal:
Different .desktop files for each plugin and a new field: MIMEMergeInto.
Example:
gst-player.desktop <-- Installed by the gst-player package [1]
gst-player-mpeg.desktop <-- Installed by gst MPEG plugin package,
contents:
[Desktop Entry]
Encoding=UTF-8
MIMEType=video/mpeg
MIMEMergeInto=gst-player.desktop

gst-player.desktop will then support both, self.MIMEType and gst-player-
mpeg.MIMEType mime types.
Does the spec allow this kind of cropped entries? Does it form a huge
performance impact?

regs,
 Chris

[1] http://packages.debian.org/unstable/gnome/gstreamer-player