proposal request: virtual MIME types unknown in time of installation
sbrabec at suse.cz
Wed Feb 28 02:59:56 PST 2007
Stanislav Brabec wrote in Wed Nov 16, 2005 at 14:41 +0100:
> As a package maintainer, I meet often with two calls for MIME type
> 1) Application uses back-end for file operations.
> E.g. eog can open everything, what can provide gdk-pixbuf-loader
> Using hardwired MIME type list in the eog.desktop is an ugly
> 2) Application can open more MIME types using plug-ins.
> E.g. gimp can open image/x-dcraw only if RAW photo plugin is installed.
> Using hardwired MIME type list with MIME types for all plugins and
> adding MIME type description XML file to plug-in is an ugly work-around.
I have just revived my old proposal and tried to look at keywords available in the current spec.
I found following ways to define them, changing or not changing spec.
Please look at it and let me know, what looks better.
First additionally adds sub-class-of virtual/foo to the image MIME type,
second one defines new keyword and adds and extends definition of
1) Keep current spec, change implementation:
With current implementation, it is possible to define:
<?xml version="1.0" encoding="UTF-8"?>
It does nearly what we need and surprisingly it works with
update-mime-database and does not break MIME type definition (only
But looking at implementation in Nautilus, it does not exactly, what we
expect: Nautilus interprets sub-class MIME types as low priority
candidates for opening MIME type - it offers them in sub-menu, but not
as default. This behavior seems to be correct (because nobody wants to
open SVG in the XML or text editor as a default application).
Additionally, it seems that Nautilus offers only applications coming
with the first sub-class-of line.
We can work-around this problem saying, that virtual/* MIME types are
special and candidates offered by this way are good candidates.
No spec change needed
Needs change in implementation
2) Define new keyword into spec.
Proposed keyword is logically reversed, but not reversed in
functionality, I don't propose name "super-class-of", but name
> <?xml version="1.0" encoding="UTF-8"?>
> <mime-type type="virtual/gdk-pixbuf-loader">
> <provides type="image/x-dcraw"/>
Looks more logical.
No "hijacking" of existing definitions.
Needs change in spec.
Needs change in implementation.
Best Regards / S pozdravem,
SUSE LINUX, s. r. o. e-mail: sbrabec at suse.cz
Lihovarská 1060/12 tel: +420 284 028 966
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
More information about the xdg