mime-type/application association spec

[Heinrich Wendel]

On Wednesday 11 June 2003 16:08, Christophe Fergeau wrote:
> > 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).
This is what I meant with a standard for uris: We have gnome-vfs and kioslave, 
they have both a uri scheme, home:/// or smb:// for example, we could also 
specify a standard for this, but so long I think this extensions should be 
"X-" marked and not go into the spec.

>
> > 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, ...)
Hm not quite sure if this is necessary. Can you give me a more specific 
example, where and whereto this is used in gnome?

>
> > >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 think.
>
> 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
> probably enough.

Seems also good for me.

>
> > 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 ;)

The html version of the spec is not uptodate, you have to read the sgml 
version. I'm also proposing some updates to this spec atm (take a look at 
https://listman.redhat.com/archives/xdg-list/2003-June/msg00013.html and 
http://cojobo.net/~h_wendel/stuff/desktop-entry-spec.html)

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

> 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
> same place.
> 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".

The specific implementations could add a cache option, but I don't think this 
should be in the official spec.

>
> Christophe
Heinrich :)