22

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?

grigoryvp
  • 40,413
  • 64
  • 174
  • 277

3 Answers3

31

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.

ptomato
  • 56,175
  • 13
  • 112
  • 165
  • Thanks for the list! Is it any API available in GTK that can list all icons from this list that GTK can load? – grigoryvp Sep 25 '11 at 07:16
  • No, because it should be able to load all of them. If not, then it's a bug. Report it at bugzilla.gnome.org ;-) – ptomato Sep 25 '11 at 07:47
  • It's not a bug. GTK+ expects the icons to be in the normal Linux/freedesktop path or an equivalent, and 3rd party packagers/users working on other OSes usually just don't set up their environment to provide that. – underscore_d Sep 07 '16 at 12:11
6

Better late than never !

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

nocbos
  • 391
  • 1
  • 4
  • 6
4

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.

underscore_d
  • 6,309
  • 3
  • 38
  • 64