Mimetype Activation (Was: Shared mimetypes + activation)

[Alexander Larsson]

On Fri, 2004-04-23 at 10:06, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Mimetype activation / mimtype actions is a somewhat complex set of issues. I 
> will try to give an overview of the requirements in this area based on 
> http://www.gnome.org/~jrb/files/mime/ and current KDE usage.
> 
> R1) Applications can be associated with a mimetype to indicate that files of 
> that mimetype can be opened with that application (Open)
> R1-1) Users should be able to associate an application with an additional 
> mimetype
> R1-2) Users should be able to remove an association between an application and 
> a mimetype
> 
> R2) At most one application can be associated with a mimetype as the preferred 
> application to use for opening files of that mimetype (Primary Application)
> R2-1) Users should be able to select the Primary Application out of all 
> applications able to open a given mimetype.
> R2-2) Users should be able to order on preference all applications able to 
> open a given mimetype. (currently available KDE functionality)
> R2-3) A mechanism must be in place to determine the Primary Application if the 
> user has not explicitly selected such Primary Application for a given 
> mimetype.
> 
> R3) Actions other than Open can be associated with a mimetype to indicate that 
> such action can be performed on files of that mimetype. (Actions)
> R3-1) Actions should have an associated icon, a translatable caption and 
> possibly a description and, most important, a description of how to activate 
> the action (such as an Exec= line for example)
> 
> R4-1) The Open action may be associated with a desktop/browser specific 
> loadable component (KPart, Nautilus component) instead of an application.
> R4-2) Actions may be associated with a desktop/browser specific loadable 
> component (KPart, Nautilus component) instead of an application.
> 
> Does this look somewhat complete? For some of these (The R4s for example) we 
> may choose not to include them in a standard but they should probably still 
> be kept in mind while creating the standard

Another important thing to keep in mind here is mime aliases. If we e.g.
add a mime type for .php files (say text/x-phpsrc) suddenly all *.php
files are of that type, and an editor registered to handle text/plain
won't be used to open it. So, we need some sort of aliases, allowing you
to have a specific default handler for text/x-phpsrc, but if none
exists, we use the one for text/plain. And the list of all apps handling
the file should contain both the text/plain and the text/x-phpsrc
handlers.