Re: Important desktop-wide change (MIME)

On Fri, 2004-07-23 at 10:31, Christian Neumair wrote:
> Am Mittwoch, den 21.07.2004, 18:33 +0200 schrieb Sven Neumann:

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

Like I said, run update-mime-database - which has to be done no matter
what, because no matter what method we use, the database has to be
updated.  Just put the call in the postinstall script of the package.

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

The problem here is then plugins need to know what applications they
affect.  A GStreamer plugin won't know that; it doesn't just affect
GSTPlayer, it also affects Rhythmbox, Totem, or any application that has
multimedia usage.  If we went with macros, as Havoc called them, it
would work better.  Each app would specify that it supports the plugin
category "gstreamer" (by just listing a special MIME type like
x-virtual/gstreamer, or something), and the individual plugin .desktop
files would state that they are in the x-virtual/gstreamer MIME

The only performance impact I can see is that whenever someone needs to
scan the available .desktop files, there will be a bunch of entries that
are quite useless (wasted time stating them, reading them, parsing them,
etc); if those kinds of "virtual" .desktop files were put somewhere
other than the main applications folder, so menu code can completely
ignore them and just update-mime-info would ever need to see them, there
would be zero performance impact.

> regs,
>  Chris
> [1]
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]