Hi, Since there didn't seem to have much activity to write a doc specifying how mime-type/application associations could be handled in a cross-desktop way, I decided to give a try at such a spec. Attached to this email, you'll find a rough draft describing one possible way of doing that. Keep in mind that it's a very preliminary draft whose main goal is to start a discussion. There are probably many problems I didn't think about, it only talks about GNOME specific stuff since I don't know how this problem is handled in other desktop environments. However, I took various idea from posts on this mailing list, so some parts of this document are probably quite similar to what KDE is currently doing. So here is the document (it's also available from http://cfergeau.free.fr/mime-spec.txt), any comment is welcome, Christophe
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. It's not possible to associate a mime-type with an app which don't have an associated .desktop file. Several .desktop files can be concatenated in a single file to avoid having tons of files (FIXME: is that compatible with the .desktop spec ?) Extensions to the .desktop file format: ====================================== Extension to .desktop files describing an application: They can contain a field MimeType which 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, ...)). Need to be able to store lots of .desktop-like files in a single file (for efficiency reason and to replace gnome-vfs.applications) Other fields necessary (to provide equivalent functionality with what is currently in GNOME): 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 uses_gnome_vfs will be a gnome extension supported_uris: gnome or not gnome ? (this currently lists the various url schemes an app can open: http, ftp, ...) => this allows app writer to easily associate their app with specific mime types without having to create tons of files Mime-type storage ================= => Use the xml mime type format described in the current shared mime spec, with some customizations. Store all mime types in a single file (efficiency reasons => multiple files = 50% slower (according to my totally unscientific tests)) 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> Extensions which will be gnome specific: default action type (component/application) component association 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) 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 FIXME: how to store app-specific info in the database? (to allow app writers to associate app-specific info to mime types) add custom xml attributes with proper namespacing ? 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 ?
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=