mime-type/application association spec
teuf at users.sourceforge.net
Wed Jun 11 17:08:25 EEST 2003
> Yes, there seems now to be a format for the mime-types but not how to
> associated applications to mime-types. I suppose to do it similar like KDE
> does it. The MimeType Key is alreay in the Desktop specification, so we have
> no problems here.
I must admit I haven't read the .desktop spec really carefully, I should
reread it once or twice.
> can_open_multiple_file: Why do we need that? Take a look at the exec
> parameters you have %f, a single file name, and %F an list of files names.
As I wrote in the file, it's not completely obvious, people who write
.desktop files for their app may miss it. Nothing which can't be fixed
with a bit of doc though :)
> uses_gnome_vfs: Again why? Backward compatibility?
As I said in the file, this one is not really meant to go in a shared
spec, but rather an extension that gnome would need to add. gnome is
currently using this to indicate that an app is using gnome-vfs, which
means this app can open any url scheme known to gnome-vfs (the list of
supported schemes can't be known when the app is installed or written).
> supported_uris: Interesting topic to think about, but I don't think it has to
> be in this specification, mainly this uris are all opened by
> nautilus/konqueror, so we should think about a specification for this uris,
> but not to add them to this standard.
I don't understand what you mean there :) This entry was once again
copied from what gnome is doing, this is used by apps which aren't using
gnome-vfs to tell which kind of uri they can open (eg, galeon would
declare file: http: and ftp:, wget would put http: and ftp: there, ...)
> >Store all mime types in a single file (efficiency reasons =>
> >multiple files = 50% slower (according to my totally unscientific tests))
> Maybe it's faster, but it's difficulter to maintain, so I think we do not need
> this file at all. The priority is done via the InitialPreference Parameter I
more difficult to maintain ? this file would be auto generated, in
exactly the same way that the mime type tree is built in the shared mime
spec (using some prog whose name I forgot). Though the approach
suggested by Thomas Leonard of only loading those files on demand is
> So all in all I would propose to standarize the KDE extensions to the .desktop
> format. But why standarize them, they are already standard, but this is not
> widely known ;D
I must reread this spec, it seems I missed some parts of it ;) I didn't
see this InitialPreference parameter, and I was a bit confused by the
MimeType explanations, I thought this field was deprecated, or limited
to .desktop files not describing an app, or something like that.
Hopefully I'll understand all of this better tonight ;)
Even if the .desktop spec contains most of what is needed, we still need
a way for the user to add/remove helper apps for each mime type, and to
specify how these changes should be saved.
A way for app writers to add info to mime-types would also be nice imo
(for example, a web browser may want to set a "always save to disk files
with this mime type without asking anything"). These are per-app
settings, so one may argue it's pointless to have that in a shared spec,
but imo it would be cleaner if everyone put their customizations in the
With this "only use .desktop files to store mime associations" approach,
I'm also a bit concerned with speed: there are potentially hundreds of
small files to parse at once the first time you want to know "which apps
are associated with this mime-type".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Ceci est une partie de message
Url : http://lists.freedesktop.org/archives/xdg/attachments/20030611/3f37a6bf/attachment.pgp
More information about the xdg