GNOME Bugzilla – Bug 171595
MIME subclassing implementation unusable
Last modified: 2005-08-09 22:43:09 UTC
Suppose you have installed CVS version of shared-mime-info and files
dsc_0001.nef (camera raw file in TIFF container) and pict0001.mrw (camera raw
file in non-standard container) and you will install GNOME RAW integration
Now you want to open these files using GNOME MIME system in nautilus. mrw file
is opened correctly by GIMP, opening of nef file displays MIME conflict warning
(which is correct, too). Up to this moment, everything is correct.
Because you know, that raw files can be integrated into TIFF and JPEG
containers, you will add two lines into /usr/share/mime/packages/dcraw.xml,
re-run update-mime-database /usr/share/mime and update-desktop-database.
One could expect, that nautilus will now open both mrw and nef without any
problems. But what really happens: Nautilus will now open both files, but in
gqview, which can open JPEG and TIFF, but not raw files.
Using exactly the same scheme, Nautilus offers opening SVG files in Bluefish
HTML editor (because SVG is subclass of XML and Bluefish can open XML).
To block this behavior, I have tried to comment out xdg_mime_get_mime_parents()
This gives better results, but still recognizes nef file as TIFF. I think, that
MIME type guessing should be reversed for subclasses. Example: File has suffix
nef, which is registered for image/x-dcraw. The same file has contents
image/tiff. But because image/x-dcraw contains sub-class-of image/tiff, the file
should be recognized as image/x-dcraw, not image/tiff.
Current implementation can be kept, but only as addition to fixed
implementation, to find "potentially related applications".
Nautilus then can offer for SVG "Potential application" (fixed implementation;
applications, which declare to open SVG), "Related applications" (old
implementation; applications, which declare to open any parent class, e. g. XML)
and "All applications" (the rest).
How to repeat it: Install RAW integration kit (including gimp-2.2.desktop
editing), add upper mentioned lines. Create any TIFF file, rename it as
image.nef. MIME subsystem MUST think, that it is image/x-dcraw and MUST open it
by GIMP, the only registered application, which can open image/x-dcraw.
Lines added to dcraw.xml for testing subclasses:
Thanks for your bug report!
gnome-vfs has been recently synced with xdgmime (2005-04-17). Maybe you could
try to checkout a CVS HEAD version of gnome-vfs and try out whether this works
for you now? There seems to have been some progress in xdgmime wrt MIME subclassing.
It does not offer Bluefish HTML Editor as default for opening SVG (but still
lists it), even after removing defaults.list.
But something is still bad:
Suppose you have Digital Camera RAW file (suffix .nef) resp. Video Microsoft WMV
file (suffix .wmv). Open the directory in Nautilus, view as list - you see
correct MIME types for both. But if you click to file (by left or right button),
Nautilus will change its MIME type to Image TIFF resp. Video Microsoft ASF.
IMHO there is missing this rule for context based guesses:
if ( (Suffix says type A) and (Contents says type B) and (A has type B in
sub-class-of list) ) then type is A
In other works: B is legal container type for A.
Note that some MIME types can have more container types, so A can be
sub-class-of more MIME types.
Note that my system (SuSE Linux 9.3) includes fix for WMV:
Created attachment 46373 [details] [review]
My solution :)
That should fix the issue. Would love to see some testing and feedback. Many
thanks for the bug report!
Created attachment 46374 [details] [review]
Forgot to comment. I commited the above patch to CVS head. Stanislav could you
confirm it is working? If not please reopen. Sorry for the spam!
Works nice for both NEF and WMV. Thanks.
Two additional notes:
Maybe your new code can replace hardcoded compressed type list in
gnome-vfs-mime.c, if subclassing will be well defined.
I wrote a small patch to Nautilus to allow to open file in case of MIME conflict
(see bug 154074, I have GNOME 2.10 version, too). Maybe better patch can be
created (don't display if both types will be opened by the same application and
offer both suffix and context based applications, if there is a conflict).
I do like the patch, but the bug is wrong.
These imply that all image/x-dcraw are image/tiff. It also implies that all
image/x-dcraw are image/jpeg. This is clearly wrong since tiff files can't be
The problem is that an object can be of multiple mime types even if neither type
is a subtype of the other. Perhaps the mime system needs to be modified to
return a list of mime types with priorities. file extensions should count as a
priority of 80, based on what the standard says.
Maybe globs should be able to have priorities. Like *.xml should be < 50.
Just some random thoughts.
I don't know, whether it is correct, but it helps a bit - nautilus does not
complain, if it detect raw file with contents looking like TIFF or JPEG.
What exactly I need is to say: "Image with one of the raw suffixes _can_ look
like image/tiff or image/jpeg. This fact should not be considered as MIME type
conflict and such file should be recognized as image/x-dcraw."
As addition to prioritizing of MIME type detection can be transitivity
definition. It can define container type and possible file types inside.
Current MIME standards mixes container MIME types and contents MIME types and
this fact causes problems.
File with contents type of image/tiff can be image/tiff,