Разрабатывая в 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
, правильной версии, скомпилированной правильным компилятором.