Где GTK находит имена значков для использования с gtk_image_new_from_icon_name()?

GTK может создавать изображения по имени "значок из текущей темы значка". Например:

#!/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()

Это отобразит окно с красивой стрелкой внутри него. Но - только на ubuntu. В Windows или OSX он отобразит окно с иконкой "no image" внутри:( Итак, мои вопросы: где GTK хранит имена значков, такие как "go-jump"? Является ли этот список или спецификация доступными, например, для значков акций? Может быть, это какой API GTK я могу использовать для отображения таких значков?

Ответ 1

Имена указаны в Спецификации именования значков. Если это не работает в Windows или OSX, сообщите об этом как об ошибке. Для нормальной работы GTK требуется хотя бы одна тема значков.

Ответ 2

Лучше поздно, чем никогда!

Вот два небольших сценария Python, показывающие все существующие значки, отсортированные по их имени:

http://dl.0xdeadc0de.fr/misc/gtkiconview_freedesktop.py для тех, кто указан в спецификации именования значков.
http://dl.0xdeadc0de.fr/misc/gtkiconview_local.py для тех, которые включены в пакеты, такие как "gnome-icon-theme-symbolic".

Ответ 3

Развиваясь на Debian, но требуя кросс-платформенной поддержки, я недавно установил gtkmm и co как в Windows, так и в OS X через MSYS2 и Homebrew соответственно. В стороне, gtkmm, MSYS2 и Homebrew - отличные проекты и хорошо выглядят (у меня нет аффилированности blah blah).

В то время, я думаю, я получил достойное понимание того, почему это происходит и как его исправить.

Почему

Это не ошибка в GTK +, как предполагает принятый ответ. Это факт жизни при использовании библиотеки, адаптированной к Linux на другой платформе, через среду, которая создает изображение, подобное Linux.

В Linux у вас есть единая среда со стандартизованной файловой системой - через спецификации FHS и FreeDesktop - с иконками всегда в /usr/share/icons.

Напротив, на других платформах вы устанавливаете Linux-подобные среды для компиляции, а иногда и во время выполнения, каждая со своей собственной виртуальной файловой системой - которую трудно отследить другими программами, не делая опасные вещи для конечного пользователя PATH, особенно если вы пытаетесь использовать несколько таких сред... Вы получаете идею. Конечным результатом является то, что ваша программа по умолчанию не нуждается в понимании того, где находится ваш виртуальный корень среды.

Как

Решение, которое я нашел, заключается в том, чтобы скопировать все необходимые ресурсы в ту же папку, что и ваш исполняемый файл, то есть каталог, который вы, в конечном счете, перераспределите, или если вы пишете OSS, сделайте это в своем makefile или например. Это потому, что, насколько я могу судить, программа, ищущая ресурсы GTK +, библиотеки DLL и т.д., Проверяет свой собственный каталог перед (возможно, не помогает) PATH. Немного противоположно тому, как раковины делают что-то, но удобно!

Итак, вы копируете соответствующие темы значков, установленные вашим диспетчером пакетов, в новую папку в указанной директории. Как минимум, сделайте это для стандартной темы: скопируйте ее на $YOURDIR/share/icons/Adwaita. Затем перезапустите свою программу. Если вы похожи на меня, теперь все значки работают отлично.

То же самое относится к практически любому другому ресурсу, который необходимо перераспределить с вашим приложением.

В частности, я бы предложил сделать то же самое со всеми DLL, которые нужны вашему двоичному файлу. Они могут или не могут работать для вас из коробки и в зависимости от того, как вы вызываете свой двоичный файл, - но вы действительно не можете позволить себе размышлять о том, есть ли у ваших конечных пользователей нужный набор DLL, установленных где-то в их PATH, правильной версии, скомпилированной правым компилятором.