GFileIcon, GThemedIcon, etc. are not derivable
The class/object structures for GFileIcon
and GThemedIcon
are not currently public, so there is no way to create derived classes. This restricts third party code to using the GIO classes directly, and attaching additional data to instances of them using (for example) g_object_set_data()
.
In practice, any third party code which deals with icons and uses GTK has to use icon classes which are (derived from) GFileIcon
and GThemedIcon
because GTK (and any other library which consumes GIcon
s) has a lot of code along the lines of:
if (G_IS_THEMED_ICON (icon))
/* do something performant */
else if (G_IS_FILE_ICON (icon))
/* do something similarly performant */
else if (G_IS_LOADABLE_ICON (icon))
/* do something less performant */
else if (G_IS_ICON (icon))
/* do something pretty slow */
else
/* just fail */
In particular, there is no way to hit the fast paths of loading icons by icon-name from a GtkIconTheme
if you’re not using GThemedIcon
, or getting a GtkImage
to magically reload an icon when the icon theme changes; even if your third party code deals exclusively in icon names.
Overall, it seems like GThemedIcon
and GFileIcon
should actually have been interfaces, implementable by third party code.
Use case: icon handling in gnome-software (see gnome-software#1147 (closed)), where icons come from an AsIcon
, which can provide an icon name, local filename, remote filename, or local cached filename.