Где GTK находит имена значков для использования с gtk_image_new_from_icon_name ()? - PullRequest
14 голосов
/ 24 сентября 2011

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()

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

Ответы [ 3 ]

18 голосов
/ 24 сентября 2011

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

6 голосов
/ 10 августа 2015

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

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

1 голос
/ 24 апреля 2016

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

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

Почему

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

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

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

Как

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...