Where GTK finds icon names to use with gtk_image_new_from_icon_name()?

Question

GTK can construct images by name of the "icon from current icon theme". For example:

#!/usr/bin/env python
import gtk; wnd=gtk.Window(); img=gtk.Image();
img.set_from_icon_name( "go-jump", gtk.ICON_SIZE_BUTTON );
wnd.add( img ); img.show(); wnd.show(); gtk.main()

This will display a window with a pretty arrow inside it. But - only on ubuntu. On Windows or OSX it will display window with a "no image" icon inside :(. So my questions is - where GTK keeps icon names like "go-jump"? Is it some list or specification available like for stock icons? Maybe it's some GTK API i can use to list such icons?

Answer 1

The names are in the Icon Naming Specification. If this doesn't work on Windows or OSX, then report it as a bug - GTK needs at least one icon theme installed in order to work properly.

Answer 2

Better late than never !

Here are two little Python scripts showing all existing icons sorted by their name:

• http://dl.0xdeadc0de.fr/misc/gtkiconview_freedesktop.py for those in the Icon Naming Specification.
• http://dl.0xdeadc0de.fr/misc/gtkiconview_local.py for those included in packages such as 'gnome-icon-theme-symbolic'.

Answer 3

Developing on Debian but wanting cross-platform support, I've recently installed gtkmm and co on both Windows and OS X, via MSYS2 and Homebrew respectively. As an aside, gtkmm, MSYS2, and Homebrew are excellent projects and well worth a look (I have no affiliation blah blah).

In that time, I think I've gained a decent understanding of why this happens and how to 'fix' it.

Why

This is not a bug in GTK+, as the accepted answer suggests. It's a fact of life when using a library tailored to Linux on another platform, via an environment that creates a Linux-like picture.

On Linux, you have a single environment with a standardised filesystem - via the FHS and FreeDesktop specs - with icons always in /usr/share/icons.

In contrast, on other platforms, you install Linux-like environments for compilation and sometimes runtime, each with its own virtual filesystem - which is difficult to track by other programs, without doing dangerous things to the end-user's PATH, especially if you're trying multiple such environments... You get the idea. The end result is that your program, by default, doesn't necessary have any awareness of where your environment's virtual root resides.

How

The solution, I've found, is to copy all required resources to the same folder as your executable - i.e. the directory you'll eventually redistribute, or if you're writing OSS, do this in your makefile or such. This is because, as far as I can tell, a program - looking for GTK+ resources, DLLs, etc. - checks its own directory before the (probably not helpful) PATH. A little opposite to how shells do things, but handy!

So, you copy the relevant icon themes, as installed by your package manager, into a new folder within said directory. At a minimum, do this for the standard theme: copy it to $YOURDIR/share/icons/Adwaita. Then restart your program. If you're anything like me, now all the icons work perfectly.

The same applies for pretty much any other resource that you need to redistribute with your application.

Notably, I'd suggest doing the same thing with all DLLs needed by your binary. These may or may not work for you out-of-the-box and depending on how you invoke your binary - but you really can't afford to speculate about whether your end-users already have the right set of DLLs installed somewhere in their PATH, of the right version compiled by the right compiler.