GNOME Bugzilla – Bug 144687
add API to access filesystem mimetype icons
Last modified: 2013-01-20 22:52:43 UTC
The design spec for the new filechooser widget mentions (at the bottom of http://www.gnome.org/~seth/designs/filechooser-spec/): "Long term: it may not be possible to have programs specify icons for each file type with the current API, but it would be good to have this long term as it reinforces the mapping between file types and icons at the first point people encounter them, and increases the ease of recognition in selecting from different file types." This refers to the filetype combo-box that an application is supposed to add. Seth is completely right here that such a combo should use the mime-type icons that are used in the filechooser. The problem is that the GTK+ API that would allow to do this is marked as semi-private and unsupported (in gtkfilesystem.h). IMO GTK+ should export a supported API that allows apps to render the mime icons provided by the filesystem backend.
Created attachment 29661 [details] missing icons Notice some of the icons are missing. Is this a result of this bug? These icons show up fine in 'Computer' and in the nautilus.
No, your missing icons are certainly not related to this bug report since it's not actually about a bug but about a missing feature (or more precisely a missing API). You'd better file a different bug report for your missing icons. But you should try to provide more information, for example what icon theme you are using and which GtkFileSystem backend.
I also would need an API to access GTK+'s mime-types icons (Sorry, for this "me, too" entry, but there have past nearly two years) I'd need them for a file-TreeView widget. At the moment I show some icons I found somewhere on the net, but they are butt-ugly and though I could copy your artwork and code I don't really see the sense ...
I also would like an API to access GTK+'s mime-type icons. We seem to be going at the rate of one "me, too" comment every two years. :)
this is going to be solved by GIO in GLib: GFile *file = g_file_new_for_uri (some_uri); GFileInfo *info = g_file_query_info (file, G_FILE_ATTRIBUTE_STANDARD_ICON, 0, NULL, NULL); GIcon *icon = g_file_info_get_icon (info); and retrieve the file name (or the icon theme name) from the GIcon object: if (G_IS_FILE_ICON (icon)) { GFile *file = g_file_icon_get_file (G_FILE_ICON (icon)); if (file) return g_file_get_path (file); } else if (G_IS_THEMED_ICON (icon)) { /* is this even needed? probably the G_IS_FILE_ICON check above * is enough to get the right icon for the file */ gchar **names = g_themed_icon_get_names (G_THEMED_ICON (icon)); if (names) return g_strdup (names[0]); } probably, this code warrants an helper function inside the one-level-above-glib library (be it called gbase, gdesktop, gsystem, gwhatever).
Thanks for implementing this. I have two remarks two the sample-code: 1. The line with g_themed_icon_get_names (at the end) should actually read (at least with GTK+ 2.18): const gchar* const* names = g_themed_icon_get_names (...) 2. g_themed_icon_get_names only returns the name of the icon-type to use (sort of the mime-type), not the actual file of the icon. I don't have code for C/GTK+, but in C++/Gtkmm the actual handling is like this: if (names) { Glib::RefPtr<Gtk::IconTheme> theme (Gtk::IconTheme::get_default ()); while (*names) { try { return theme->load_icon (*names, 16); } catch (...) { } ++names; } } I.e. one must get the icon-theme and ask this to load the icon matching the type; if loading fails (i.e. icon not available) use defined fall-backs. After this changes works great. Thanks a lot!
Considering this solved by gio