GNOME Bugzilla – Bug 547771
GContentType has no equivalent of xdg_mime_get_mime_parents()
Last modified: 2013-02-03 03:57:12 UTC
It would be useful if GContentType had an equivalent of xdg_mime_get_mime_parents(), ie a function that given a MIME type returns a list of parent MIME types. I see in gio/gcontenttype.c that _g_unix_content_type_get_parents() essentially does just that, but is not public (and UNIX only, obviously). Here's a use case where such a functionality would be useful : Bob finds that his GContentType-enabled desktop search system doesn't index files of MIME type A that he creates with SuperDuperOffice. He knows that the program a2text can convert those files to plain text so he goes and adds this program as an helper program to his desktop search application for type A. SuperDuperOffice also happens to generate files of format A1, a child type of A. No helper program is defined for A1, but since A is its parent type, the desktop search system is able to magically index files of type A1 too. I hope this makes sense. Fabrice fabrice.colin@gmail.com
Do you think it will be sufficient for the desktop search application to use g_content_type_is_a() to find out that A1 is in fact a subtype of one of the types it knows to handle ?
Hi Matthias, (In reply to comment #1) > Do you think it will be sufficient for the desktop search application to use > g_content_type_is_a() to find out that A1 is in fact a subtype of one of the > types it knows to handle ? > Yes, it could use this function, even though it deals with content types and not MIME types, and that there's currently no mean to get the content type for a given MIME type. It's not optimal but it would work at least on Unix. Fabrice fabrice.colin@gmail.com
There is g_content_type_from_mime_type() and g_content_type_get_mime_type() so you should be able to go back and forth between content types and mime types.
H Matthias, (In reply to comment #3) > There is g_content_type_from_mime_type() and g_content_type_get_mime_type() so > you should be able to go back and forth between content types and mime types. > Thanks for pointing this out, I didn't notice unstable had g_content_type_from_mime_type(). Relying on g_content_type_is_a() flattens the types hierarchy, eg the application can easily determine that "text/rdf" is related to "text/plain" and "application/xml", but not that "application/xml" is its immediate parent. Sure, that hierarchy could be built by the application by comparing the whole list of supported types via g_content_type_is_a(), but it would mean duplicating information known internally by GContentType/xdgmime. I hope this makes sense. Fabrice fabrice.colin@gmail.com
> I hope this makes sense. Sure, but I doubt that an application has any business investigating the mime type relationships in more detail than "is-a" reveals. There is no inherent meaning to the detail that text/rdf is an immediate child of application/xml, vs say, a grand-grand-child...
(In reply to comment #5) > Sure, but I doubt that an application has any business investigating the mime > type relationships in more detail than "is-a" reveals. There is no inherent > meaning to the detail that text/rdf is an immediate child of application/xml, > vs say, a grand-grand-child... > There is meaning to this. In this specific case, it would tell the application that RDF is more closely related to XML than to plain text, and that the XML filter is likely to do a better job than the plain text filter. Fabrice fabrice.colin@gmail.com
> There is meaning to this. In this specific case, it would tell the application > that RDF is more closely related to XML than to plain text, and that the XML > filter is likely to do a better job than the plain text filter. Really, the application would do better to know that on its own. The mime system is not a good place to get it from...
(In reply to comment #7) > > There is meaning to this. In this specific case, it would tell the application > > that RDF is more closely related to XML than to plain text, and that the XML > > filter is likely to do a better job than the plain text filter. > > Really, the application would do better to know that on its own. > The mime system is not a good place to get it from... > How so ? The type hierarchy is known to the MIME system and to xdgmime, exported by GContentType (not publicly, via _g_unix_content_type_get_parents) for use in GDesktopAppInfo. For "the application to know that on its own", it would have to duplicate the work and gain knowledge of the hierarchy some other way. That seems convoluted... Fabrice fabrice.colin@gmail.com
*** Bug 584388 has been marked as a duplicate of this bug. ***
In the Sugar shell, the journal will give the user the option of using an entry (file) as the starting point of several activities (apps). Activities are encouraged to store their state in the journal using simple formats based on plain text, png, xml, etc in order to improve hackability and make easier data exchange between activities. The result of this is that the products of some specialized activities like games are meaningful starting points for other more generic activities like a text editor or a drawing app. That's why the shell needs to know if this file with mime type image/x-crazy-paint is a image/png and thus can be opened as well in the Paint activity. Another approach would be to adapt AppInfo and .desktop files to our needs, but our targeted experience is different enough that that seems to be much more trouble.
Created attachment 138193 [details] [review] first try The win32 func builds fine in mingw in F11, but haven't tested it.
Created attachment 138194 [details] [review] fix typo
Not sure I follow. Surely, image/x-crazy-paint would be a subtype of image/png in this case ? Why does g_content_type_is_a not fit the bill ?
(In reply to comment #13) > Not sure I follow. Surely, image/x-crazy-paint would be a subtype of image/png > in this case ? Why does g_content_type_is_a not fit the bill ? g_content_type_is_a() would work though would need to be executed once for every mime type (1.5?) supported by every installed activity (several dozens) when checking which activities can use that file as their starting point. I think it's fine for our use case, but will make our code more convoluted. I still think there would be some value in exposing this API directly but I'm not the one who has to maintain glib, so...
Our hesitation to add this is partly because while this hierarchy has a very specific meaning in the freedesktop.org mime standard its not really a generally standardized thing and may mean slightly different things on other platforms (and in fact the freedesktop mime standard slowly changes over time too). So, we'd like as much as possible to expose the highlevel operations required instead of all the plumbing that is needed to implement them. For instance, the stuff Tomeu Vizoso talks about is already availible and in use by e.g. nautilus by using g_app_info_get_all_for_type() which automatically takes care of things like mime aliases and mimetype hierarchies.
Hi, Sorry to wake up this bug. I understand the hesitation. But in our case, it's just like `get_comment`. `sub-class-of` is a meta data of a MIME type, from the shared MIME database. Here we have XML packages that provides categorization. And it would be nice to not parse twice the parents tree. _g_unix_content_type_get_parents is already implemented at http://git.gnome.org/browse/glib/tree/gio/gcontenttype.c#n432. That would be nice to have it public ;-) Anyway, gio MIME is very fast and accurate. Kudo for the big job. Very good alternative to file and magic ! Regards, Étienne BERSAC