mime-type/application mapping spec, take #2

Sun Jun 29 15:51:59 EEST 2003

Le dim 29/06/2003 Ã  01:24, David Faure a Ã©crit :
> > 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?

I changed the spec to do that since that's indeed logical. What I meant
with that comment is that if I was an app writer reading the spec to
write a desktop files, I'd miss the %. part more easily than a dedicated
field.

> I suggest SupportedProtocols - or just Protocols maybe? - instead of
> SupportedURIs since this lists protocols, not full URIs.

I changed that. What about adding some special uris (maybe with a
special prefix) like kioslave, gnomevfs to indicate that the app can
open all uris supported by kde, gnome, or whatever ? Or would you prefer
a specific field for that ?

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

Yeah, this document has still many inaccuracies and problems, my goal
for now is to give a global overview of how things could work, and not
to waste too much time on the details if people don't like this spec ;)

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

I'd rather let each desktop add its extensions for now, since anyway
these fields wouldn't have the same meaning in gnome and kde, and people
using both kde and gnome may want to use the konqueror viewer while in
kde, and use a dedicated app while in gnome.

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

I added an example to clarify that in the doc, basically you add a
state="removed" xml attribute to handlers which were deleted by the
user.

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

I also got a bit more into details about that in an updated version of
my doc. In galeon for example, when you click on a file which galeon
can't handle, it proposes you to open it in an external app, or to
download it. You then have a checkbox to tell galeon to always save this
type of files to disk, or to always open it in an external app. I was
wondering if it was worth having some way to store this kind of data in
the mime spec, or if it's better to let each desktop/app decide what to
do.

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

Is kbuildsycoca a tool which is run whenever a package is installed ?
(I'm totally clueless about kde in general ;)

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

Thomas Leonard has also suggested that, but I fear this will be
insufficient. There are very few "root categories" for mime types, and
using only mime inheritance would probably not be flexible enough to
have some generic code editor, web editor or things like that.

I'm attaching a modified file taking into account most of your comments,
I also uploaded it to cfergeau.free.fr/mime-spec-0.1.txt

Christophe
-------------- next part --------------
This suggestions relies on two distinct groups of files. 

The first is the "application registry" which is created from .desktop
files and contains detailed information about an app which can be
associated to a mime-type. These .desktop files are extended so that
they can be used to specify the mime-types they should be associated 
with.

The second group is a mime hierarchy which contains the list of all 
known mime-type as well as some information about them, including 
links to .desktop files they should be associated with.

The Â« Getting the applications associated with a mime type Â» will explain
why there are those two distinct groups of files, and how to look up the 
applications associated with a mime-type.

It's not possible to associate a mime-type with an app which don't
have an associated .desktop file. When an app which does not have a 
desktop file is associated with a mime type by the user, we create
a dummy desktop file.

Extensions to the .desktop file format:
======================================

* Extension to .desktop files describing an application

1) MimeType field

This field is a list of supported mime types along with their priority. The lowest 
this number is, the more appropriate this app is to open files having this mime
type (FIXME: this doesn't fit well with the multiple-actions-per-desktop-file scheme
(ie a .desktop file doesn't describe one way to launch an app, but several: 
view, edit, ...)). 

2) SupportedProtocols field

This takes a list of protocols. When %u or %U has been used in the Exec field,
this can be used to restrict the uris the app can accept (eg, it can 
be used to tell that xmms supports http but not much more (in particular not ssh, smb, 
etc. etc.))
We could add some "reserved" protocols like "kioslaves", "gnome-vfs" to indicate that
the apps uses kioslaves, gnome-vfs, ... and can open any uri supported by this lib.
NB: There is no way for now for a gnome app to know which uris an app using kioslaves
can open, and vice-versa. 

* GNOME specific stuff

uses_gnome_vfs, or use the scheme described in SupportedProtocols ?
can_open_multiple_files (same for expect_uris) can be replaced by the 
parameters to the Exec field.

Mime-type storage
=================

=> Use the xml mime type format described in the current shared mime spec, 
with some customizations.

* Additional tags

an application will be associated with a mime type by adding a  .desktop file 
name and a priority
<mime-handler>
	<desktop-file>some-desktop-file.desktop</desktop-file>
	<priority>65</priority>
</mime-handler>
FIXME: make sure we point at a unique .desktop file, may need to add a relative 
path

Each application which is associated with a mime type must have an associated 
desktop-like file (this makes things easier if eg the user wants to associate a 
mime type with a new app which must open in a terminal). For legacy apps which don't
have an associated desktop file, we just create a dummy one if it's needed.

* User customization

If a user wants to modify/add/remove a mime-type, this will be saved in the same XML format
Removed elements will have a state="removed" attribute, the other elements present in such
a file will be assumed to have been modified/added.

For example:
<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/x-diff">
	<mime-handler>
		<desktop-file>emacs.desktop</desktop-file>
		<priority>30</priority>
	</mime-handler>
	<mime-handler state="removed">
		<desktop-file>diffview.desktop</desktop-file>
	</mime-handler>
</mime-type>

The user has added or modified emacs has a handler for .diff files, and removed diffview. 

FIXME: needs to specify where those files will be stored to be able to tell the difference
between a mime/subtype.xml file installed by the user using update-mime-db, and a
mime/subtype.xml file created as a result of a user modification of the apps associated
with this mime-type.

* Should apps be able to store their own info in the database ?

FIXME: how to store app-specific info in the database? (to allow app writers to 
associate app-specific info to mime types, for example a web browser may want
to store info like "when the user tries to download a file with this mime-type,
always save it to this directory"): add custom xml attributes with proper 
namespacing ? Does it belong in a shared spec at all since by definition it will
be app-specific ?

* GNOME specific stuff

Extensions which should be gnome specific:
default action type (component/application)
component association

Getting the applications associated with a mime type
====================================================

With the previously described extensions, there would be two ways to get the applications
associated with a mime type: by reading the MimeType field for all .desktop files, or
by looking up the xml file corresponding to the mime-type.

Actually we can't tell implementers to use these .desktop files: to find the apps 
associated with a given mime-type, implementers would need to parse all the desktop 
files, which is overkill. On the other hand, putting MimeType associations in .desktop
files is much more convenient for app writers to write and install a single .desktop file

=> mime-type info will be put in .desktop files, but will be processed by an 
update-mime-db-like program which will store the application/mime-type mappings
in the mime-type xml files. This processing will be done during the make install
of the app, or in the install process of the app package.

It is recommended that implementers don't load all the app/mime-type mapping at runtime
since it can be quite expensive timewise (especially because of the many small xml files
to parse). On the other hand, locating the appropriate xml file and parsing it when 
we need to look up the apps associated with a mime type shouldn't be too expensive. 
Moreover, the information for this mime-type can be cached for further use.

Since mime-type info is migrated from a .desktop file to a central location, and since
users can add their own handlers to mime-type, we can get to a situation where some 
mime-type should be handled by an app which has been uninstalled but is still referenced.
In such cases, the app should be ignored, and not returned as an handler for any mime-type.

Generic Handlers
================

Some kind of generic handler would be convenient: A whole group of mime type can be 
associated to a generic "text editor", this will makes it much easier for user  
to change their default text editor.
This can be achieved by having some "generic" .desktop files which only contain a link 
to another desktop file => what happens if the generic text editor is uninstalled ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.freedesktop.org/archives/xdg/attachments/20030629/22a82bc3/attachment.pgp 