Bug in MIME type detection - nautilus or vfs?

[Daniel Leidert]

Am Mittwoch, den 11.01.2006, 14:06 +0100 schrieb Alexander Larsson: 
> On Mon, 2006-01-09 at 03:41 +0100, Daniel Leidert wrote:
> > x-post to gnome-vfs and gnome-nautilus lists
again and posting to freedesktop.org's xdg list

Please tell me, on which list this is most On-Topic. I fear, that
cross-posting is not "the best" way.

> > There is a bug in the MIME type detection in nautilus. To show what I
> > mean: I have a directory, where all my bluefish-projects files resist.
> > The application/bluefish-project MIME type is defined via
> > shared-mime-info database.
> 
> On directory load nautilus only looks at the extension (for performance
> reasons), but when you actually click on the file it sniffs it. If you
> make the bluefish-project a subclass of text/plain then it won't fall
> back in that way i think. At least with later versions of gnome.

Thanks. That works. But that still leaves the minor issue, that editors,
which can handle text/plain are also listed in "Open with". After fixing
the shared-mime-info database entry for bluefish project files and
trying to open a .bfproject file from nautilus, gedit was used to open
that file, which is not the aim. Of course, the desktop-database only
lists bluefish to open application/bluefish-project and IMHO there
should be more respect to this application than any other application,
which can handle text/plain. The situation gets more complicated for
e.g. chemical/x-cml, which is a file of the Chemical Markup Language
type, which is a sub-class of text/xml, which is a sub-class of
text/plain. But only all editors, which can handle text/xml and
chemical/x-cml are listed in "Open with". So is text/xml also a
"fall-back" type? Shouldn't that whole behaviour be changed to a
solution, where only applications, which can handle the MIME type at the
top of the type tree, are listed in "Open with"? It would mean, that
really all MIME types sub-classes and "top" types must be listed in the
realted .desktop file. Or maybe one has a better idea.

Regards, Daniel