mime-type/application mapping spec, take #2

[David Faure]

> can_open_multiple_files (same for expect_uris) can be replaced by the 
> parameters to the Exec field. Seems a bit hackish and error prone though
I don't see what's hackish or error prone about it. On the contrary,
duplicating this information would end up with possible bugs like
can_open_multiple_files=true and Exec=foo %f (i.e. doesn't support multiple files).
Why not just get this information from the Exec line?

> supported_uris: gnome or not gnome ? (this currently lists the various
> url schemes an app can open: http, ftp, ...)
This would be an interesting extension. %u and %U mean "any URL"
but when SupportedProtocols (for a name more consistent with the
existing fields in the .desktop standard) is there, it could say which protocols
are supported. This allows to say that e.g. xmms supports http but not much
more (in particular not ssh, smb, etc. etc.).
I suggest SupportedProtocols - or just Protocols maybe? - instead of
SupportedURIs since this lists protocols, not full URIs.

Now on the mimetype spec extension:

> <desktop-file>some-desktop-file.desktop</desktop-file>
Just the filename isn't unique enough. This needs to be a relative path.
Hmm, or does the new .desktop menu organization mean that each .desktop 
file has a unique filename now? (Waldo?)

> Extensions which will be gnome specific:
> default action type (component/application)
We could use this flag in KDE too. It sounds equivalent to our current
X-KDE-AutoEmbed flag, i.e. whether clicking on a file should fire
an application or embed a viewer into Konqueror.

> component association
Although we need this too, we obviously can't share those. But we could design
something that contains a prefix, gnome or kde (or ...).

> user customization will be saved by adding attributes to the mime-type xml file
> indicating whether the corresponding type/info was added/removed/modified by 
> the user
This needs to be specified better. How does the user's .xml file say
"I don't want this app"? If it's just by not having it in the list, then installing
new apps doesn't make it accessible to users, which sounds broken.
Maybe a special priority value like -1?

> FIXME: how to store app-specific info in the database?
I don't understand what this is about - is that the open/view/edit stuff?
(i.e. associating a label with the mimetype-application assocation)

OK for the "letting a particular application gather the info from the .desktop
files and writing it into the mimetype xml" - i.e. a "cache" approach.
In KDE's case, kbuildsycoca could take care of that.

For the generic handler suggestion, I suggest another solution:
mimetype inheritance. Has this been added to the mimetype spec? I remember
we talked a bit about it. It would allow to let all text-based mimetypes inherit
from text/plain, which would also mean they inherit its handlers.

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
Qtella users - stability patches at http://blackie.dk/~dfaure/qtella.html