From 2a3b70fd794c64aac1dfc9d8ba567888195d0903 Mon Sep 17 00:00:00 2001 From: Jonathan Blandford Date: Tue, 13 Jul 2004 22:05:05 +0000 Subject: Update the MIME description to make it more relevent. Tue Jul 13 18:04:11 2004 Jonathan Blandford * desktop-entry-spec.xml: Update the MIME description to make it more relevent. --- desktop-entry/ChangeLog | 5 + desktop-entry/desktop-entry-spec.xml | 184 ++++++++++++++++++----------------- 2 files changed, 98 insertions(+), 91 deletions(-) (limited to 'desktop-entry') diff --git a/desktop-entry/ChangeLog b/desktop-entry/ChangeLog index 9a9fa07..8ec57c3 100644 --- a/desktop-entry/ChangeLog +++ b/desktop-entry/ChangeLog @@ -1,3 +1,8 @@ +Tue Jul 13 18:04:11 2004 Jonathan Blandford + + * desktop-entry-spec.xml: Update the MIME description to make it + more relevent. + 2004-04-19 Mark McLoughlin Pointed out by Ville Skyttä diff --git a/desktop-entry/desktop-entry-spec.xml b/desktop-entry/desktop-entry-spec.xml index 1d5716a..c890a57 100644 --- a/desktop-entry/desktop-entry-spec.xml +++ b/desktop-entry/desktop-entry-spec.xml @@ -61,16 +61,15 @@ should be simply called .directory. - The basic format of the desktop entry file requires that there be a - "group" header named [Desktop Entry]. - This "group" entry denotes that all - {key,value} pairs following it belong in - the Desktop Entry group. There may be other groups present in - the file (see MIME types discussion below), but this is the most - important group which explicitly needs to be supported. This group - should also be used as the "magic key" for automatic MIME type - detection. There should be nothing proceeding this group in the - desktop entry file but possibly one or more comments (see + The basic format of the desktop entry file requires that there be + a "group" header named [Desktop Entry]. This + "group" entry denotes that all {key,value} + pairs following it belong in the Desktop Entry group. There may + be other groups present in the file, but this is the most + important group which explicitly needs to be supported. This + group should also be used as the "magic key" for automatic MIME + type detection. There should be nothing proceeding this group in + the desktop entry file but possibly one or more comments (see below). @@ -92,18 +91,16 @@ Entries in the file are {key,value} pairs in the format: - -Name=Value + Key=Value Space before and after the equals sign should be ignored; the = sign is the actual delimiter. - The escape sequences \s, - \n, \t, - \r, and \\ are supported, - meaning ASCII space, newline, tab, carriage return, and - backslash, respectively. + The escape sequences \s, \n, + \t, \r, and + \\ are supported, meaning ASCII space, newline, + tab, carriage return, and backslash, respectively. @@ -113,16 +110,17 @@ Name=Value boolean (encoded as the string true/false), and numeric. - The difference between string and localestring is that the value for - a string key must contain only ASCII characters while the value - of a localestring key may contain UTF-8 characters. + Values of type string must contain only ASCII + characters excluding control characters. Values of type + localestring are user displayable, and are + encoded in UTF-8 unless the Legacy-Mixed + Encoding is specified (see .) Some keys can have multiple values; these should be separated by a semicolon. Those keys which have several values should have a - semicolon as the trailing character. For lists of strings, - semicolons are simply not allowed in the strings, there is no - escape mechanism. + semicolon as the trailing character. Semicolons in these values + need to be escaped using \;. @@ -372,7 +370,7 @@ Name=Value 1-4 - Hidden + Hidden Hidden should have been called Deleted. It means the user deleted (at his level) @@ -476,7 +474,7 @@ Name=Value The MIME type(s) supported by this entry. - regexp(s) + strings(s) NO NO 1 @@ -778,76 +776,80 @@ Name=Value - Detailed discussion of supporting MIME types - - It is in every desktop's best interest to have thorough support for - MIME types. The old /etc/mailcap and - /etc/mime.types files are rather - limited in scope and frankly, are outdated. Various desktop systems - have come up with different ways of extending this original system, - but none are compatible with each other. The Desktop Entry Specification - hopes to be able to provide the beginnings of a solution to this - problem. - - - At a very basic level, the Exec key provides the default action to - take when the program described by a desktop entry is used to open a - document or data file. Usually this consists of some action along the - lines of kedit %f or ee %f. This is a good - start, but it isn't as flexible as it can be. - - - Let us first establish that a program which supports a MIME type or - multiple MIME types may be able to support multiple actions on those - MIME types as well. The desktop entry may want to define additional - actions in addition to the default. The top level Exec key describes - the default action; Let us define this action to also be known as the - "Open" action. Additional actions which might be possible include - "View", "Edit", "Play", etc. A further revision of this document will - probably specify several "standard" actions in addition to the default - "Open" action, but in all cases, the number of actions is - arbitrary. - - - Let us use a sound player as a simple example. Call it sp. The - default Exec (Open) action for this program would likely look - something like: - - -Exec=sp %u - - However, imagine the sound player also supports editing of sound files - in a graphical manner. We might wish to define an additional action - which could accommodate this. Adding the action would be performed - like this: - - -Actions=Edit; - -[Desktop Action Edit] -Exec=sp -edit %u + Registering MIME Types - As you can see, defining the action "Edit" will enable an additional - group of the name [Desktop Action actionname] to be read. This - group can contain an additional Exec line, as well as possibly other - information like a new Name, - Comment, Icon, and - Path. Thus - right-clicking on a .wav file will show both the default "Open" action - and this "Edit" action to both be displayed as choices in the - context-menu. A left click (double or single, whichever the file - manager implements) would cause the default action to take place. - These are implementation specific details which are up to the - implementer, and are not enforced by this standard. + The MimeType key is used to indicate the MIME + Types that an application knows how to handle. Applications that + can handle multiple MIME Types would list all of the ones it can + handle in a ';' separated list, as normal. It is expected that + for some applications this list could become long. An application + is expected to be able to reasonably open files of these types + using the command listed in the Exec keyword. - If no DefaultApp is specified for a particular MIME type, any one of - the programs registered which claim to be able to handle the MIME type - may become the default handler. This behaviour is undefined and - implementation specific. KDE doesn't use a DefaultApp anymore, but assigns - a preference number to each program, so that the highest number is the - one chosen for handling the MIME type. + There should be no priority for MIME Types in this field, or any + form of priority in the desktop file. Priority for applications + is handled external to the .desktop files. + + Caching MIME Types + + To make parsing of all the desktop files less costly, a + update-desktop-database program is provided + that will generate a cache file. The concept is identical to + that of the 'update-mime-database' program in that it lets + applications avoid reading in (potentially) hundreds of files. + It will need to be run after every desktop file is installed. + One cache file is created for every directory in + $XDG_DATA_DIRS/applications/, and will create a file called + $XDG_DATA_DIRS/applications/mimeinfo.cache. + + + The format of the cache is similar to that of the desktop file, + and is just a list mapping mime-types to desktop files. Here's + a quick example of what it would look like: + + application/x-foo=foo.desktop;bar.desktop; +application/x-bar=bar.desktop; + + Each MIME Type is listed only once per cache file, and the + desktop-id is expected to exist in that particular directory. + That is to say, if the cache file is located at + /usr/share/applications/mimeinfo.cache, + bar.desktop refers to the file + /usr/share/applications/bar.desktop. + + + + Priority of MIME Types and desktop files + + There is also a preference list to determine preferred + application of a given MIME Type. It defines the 'default' + application to handle a given MIME Type. It has the same format + as the cache list. + + mime/type=desktop-id.desktop; + + If a mime type is listed multiple times (either in the same + file, or in another file further down the search path), the + latter mention wins. If a listed file doesn't exist, or is + precluded through the OnlyShowIn or + NotShowIn files, they should be ignored. + This means that applications will have to keep a history of the + preferred applications that they run into, so that if the top + desktop file for a given MIME Type isn't available, the second + one can be tested, etc. + + + It is also worth noting who this mechanism is defined for. It + is primarily intended for use by distributors/sysadmins to + provide a sane set of defaults for their users. Additionally, + users themselves can use this mechanism to override the user + defaults. We intentionally don't provide a way for application + authors themselves to list themselves as the default for a given + type, as we felt that that cannot work. + + Extending the format -- cgit v1.2.3-54-g00ecf