This patch adds many missing sub-class-of definitions, in particular for all text types that are subclasses of text/plain. Not all text/* types should be subclasses of text/plain. The logic is to do it only where users might want to end up with a text editor to edit them. So I added it to e.g. all "source code" mimetypes and README files etc., but not to vcard or vcalendar files, those are not really readable and much better handled by the appropriate programs. This rule isn't very easy to apply though (e.g. do people want to read/edit XSL/FO files by hand if no better editor is available? Hmm, probably). Maybe text/plain should also be added to This patch also merges the two msword types by making them aliases. Same thing for the two msexcel types and the two realaudio types. Is text/x-xmi a subclass of text/xml? text/x-xslt is one, right? Is there a relation between text/rdf and text/rss? What's text/directory text/enriched and text/rfc822-headers? Mimetypes which have just a name and a comment (no glob nor magic) don't seem very useful in fact - at least no file manager will ever end up using them. But of course they can be useful for drag-n-drop etc. I just wonder if text/directory was meant for (e.g. kde's) ".directory" files... Thanks.
Created attachment 286 [details] [review] patch
XSLT is certainly XML. Don't know about XMI, but I expect so. There are two versions of RSS. One is a subclass of RDF, the other isn't. Looks like text/directory should indeed have a glob. I'm not sure that the explicit subclassing of all the text types is necessary. The spec already says that all text/* are text/plain. This is pretty much the requirement for a type to be in the text/* group in the first place. Some plain text formats are elsewhere, eg application/x-python, precisely because they shouldn't be opened in a text editor by default. While you might not agree with all such choices, having two mechanisms for this is clearly wrong. I'd be perfectly happy to show a VCARD in a text editor, for example. I think that for all text files, opening them in a text editor is better than refusing to open them at all. The more interesting question is whether they should appear on the menu as possible actions, given that more suitable programs exist. Eg, if I have an RDF editor and an XML editor, I might want them both listed as options for an RDF file, but I might not want a text editor there. It depends a lot on the users, though.
Created attachment 459 [details] [review] Patch with just the subclasses I've applied the parts of the patch that fix the duplicate types. Here's the rest of the original patch.
Committed to CVS.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.