Created attachment 155563 [details] [review]
Patch to set the default lookup to include a generic fallback

I will try to paraphrase a conversation on #gnome-hackers regarding this about 15 minutes ago (so you can look in the logs).

mclasen and haddess are concerned that changing this would have far reaching effects.  One concern is that currently the set_icon_name function specifically states that an icon that can't be found will be replaced with a broken icon image.  So people may have relied on that functionality.  Another is that there are certain cases where the fallback might not apply, and that applying it genericly could create bad results in those cases.  The example given was: "you probably don't want to fall back from document-print-preview to document-print."

There is a work around.  And that is to use a GIcon as an intermediary, which will handle the fallback.  And then set the GtkImage using the GIcon.

Personally, I still believe that default behavor should be to use the fallback mechanism that is defined in the icon-naming-specification.  It seems that the function name "*icon_name" should tie as closely to that specification as is reasonably possible.

Given that the GtkImage API docs don't explicitely say that "icon-name" will use fallback, and that the icon naming specification doesn't allow for some types of icons to be fallen back on (eg. not for apps), this could break a number of things (eg. make some images show something wrong when they should show a broken image).

I'm pretty sure the GTK+ devels would take a patch to add documentation and/or an example for using GIcon instead.

Created attachment 274154 [details] [review]
patch: icontheme: Fallback from symbolic to non-symbolic icon

I agree with Bastien that it's risky to always use generic fallback in
GtkImage. But there is a less far-reaching kind of fallback that I think is
usually (perhaps even always) wanted: fallback from a symbolic icon to the
corresponding non-symbolic icon. If icon x-y-z-symbolic is not found,
look for x-y-z.

There are several widgets that now show the "broken image" icon if you have
selected an icon theme without symbolic icons. The attached patch fixes some,
but not all, of those.

These are files where I have found the use of symbolic icons without fallback
to non-symbolic icons:
  gtkappchooserdialog.c
  entry.c
  filechooserwidget.c
  headerbar.c (4 out of 5 symbolic icons use fallback)
  printbackend.c
  searchentry.c
  trashmonitor.c (not fixed by my patch)
  volumenbutton.c
  gtkappchooserwidget.ui
  gtkfontchooserwidget.ui
  gtkinfobar.ui
  gtkprintunixdialog.ui
  gtkscalebutton.ui
  gtksearchbar.ui

https://git.gnome.org/browse/gnome-icon-theme-symbolic/tree/README says:
"If a -symbolic icon is missing, the app will fall back to the regular name."
That is not automatically true. The app must explicitly ask for a fallback.

The documentation of the GtkVolumeButton:use-symbolic property says:
"If the symbolic icons are not available in your installed
theme, then the normal (potentially colorful) icons will be used."
That is not true. It becomes true when my patch is applied.

Other symbolic icon bugs: bug 680926, bug 708163, bug 722642.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

This issue is not important to me.
But I did not file this bug. My opinion is not important, either.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new