其中GTK从图标名称（）中查找要与GTK_image_new_一起使用的图标名称？

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上，它将显示一个内部带有“无图像”图标的窗口：（。所以我的问题是-GTK在哪里保留图标名称，如“go jump”？是否有一些列表或规范可用，如股票图标？可能是我可以用来列出此类图标的GTK API？

名称在中。如果这在Windows或OSX上不起作用，则将其报告为错误-GTK需要至少安装一个图标主题才能正常工作。

迟做总比不做强

下面是两个小Python脚本，显示按名称排序的所有现有图标：

• 对于图标命名规范中的那些
• 适用于“gnome图标主题符号”等软件包中包含的内容

---

在Debian上开发，但需要跨平台支持，我最近分别通过MSYS2和Homebrew在Windows和OS X上安装了

gtkmm

和co。另外，

gtkmm

、MSYS2和Homebrew都是优秀的项目，值得一看（我没有任何附属关系）

在那段时间里，我想我已经对为什么会发生这种情况以及如何“修复”它有了一个相当好的理解

为什么？ 这并不是GTK+中的一个bug，正如公认的答案所表明的那样。在另一个平台上使用为Linux量身定制的库时，通过创建类似Linux的图片的环境，这是一个事实

在Linux上，您有一个具有标准化文件系统的单一环境—通过FHS和FreeDesktop规范—图标始终位于

/usr/share/icons

相比之下，在其他平台上，您可以安装类似Linux的编译环境，有时也可以安装运行时环境，每个环境都有自己的虚拟文件系统——这很难被其他程序跟踪，如果不对最终用户的

路径做危险的事情，尤其是当您尝试多个这样的环境时……您就明白了结果是，默认情况下，您的程序不必知道环境的虚拟根所在的位置

怎么
我发现，解决方案是将所有必需的资源复制到与可执行文件相同的文件夹中，即最终要重新分发的目录，或者如果您正在编写OSS，则在
makefile
或诸如此类的文件夹中执行此操作。这是因为，据我所知，一个程序在查找GTK+资源、DLL等之前会检查自己的目录e（可能没有帮助）
路径
。与shell的工作方式有点相反，但很方便

因此，您可以将软件包管理器安装的相关图标主题复制到所述目录中的新文件夹中。至少对标准主题执行此操作：将其复制到
$YOURDIR/share/icons/Adwaita
。然后重新启动您的程序。如果您和我一样，现在所有图标都可以正常工作

这同样适用于几乎所有需要随应用程序重新分发的其他资源

值得注意的是，我建议您对二进制文件所需的所有DLL进行同样的处理。这些DLL可能适用于您，也可能不适用于您，这取决于您如何调用二进制文件-但您实在无法猜测您的最终用户是否已在其
路径
的某个位置安装了正确版本的DLLn由正确的编译器编译。
谢谢你的列表！GTK中有没有API可以列出GTK可以加载的列表中的所有图标？没有，因为它应该能够加载所有图标。如果没有，那就是一个bug。请在bugzilla.gnome.org上报告；-）这不是bug。GTK+希望图标位于正常的Linux/freedesktop路径或等效路径中，而在其他操作系统上工作的第三方软件包商/用户通常不会设置他们的环境来提供图标。谢谢，非常有用。