对于部分操作系统，比如 suse linux desktop enterprise 10, 在用户目录下建立 .icons/hicolor/48x48/emblems 目录并且添加 em-test.icon/png, 应用程序无法正常读取。
此问题解决的方法简单的好两种：
1.hicolor改成其他的比如 Industrial
2.在 ~/.icons/hicolor 下添加index.theme文件，该文件里包括了 48X48/emblems 的子目录描述。
但这个两个做法直觉上说都不是bug出现的根源，因为对于系统来说,不管是Industrial 还是 hicolor, 都是一个图标主题，在/opt/gnome/share/icons/下有着一样的地位，虽然Industrial或其他的会作为gnome默认的主题，但是hicolor的地位也很特殊。
而言之，/opt/gnome/share/icons 下的 Industiral 和 hicolor 目录有着类似的 index.theme 文件和目录结构，没有理由hicolor要作额外的处理。
代码跟踪到最后，锁定在 gtk源代码icon theme 部分， 具体见 gtk+-2.8.10/gtk/gtkicontheme.c的 insert_theme函数。
在该函数里，对相关主题下的子目录icon进行搜索并加载到cache里面。
主题的搜索目录除了~/.icons，就是环境变量XDG_DATA_DIRS里定义的目录,而index.theme文件则定义了搜索目录下更细微的目录，index.theme类似主题的配置文件。 比如这里说的， ~/.icons/hicolor/48x48/emblems/em-test.icon(png), ~/.icons是搜索目录， hicolor 是主题， 48X48/emblems 是hicolor主题下index.theme文件里写明的一个明细子目录，在这三个确定之下，em-test.icon/png被加载到cache里面。对于程序来说，负荷比较大的地方在于通过index.theme读取子目录以及通过子目录加载icons/pngs.
系统里存在着多个搜索目录，insert_theme里对它进行搜索并通过index.theme载入明细目录，可能出于效率上的考虑， insert_theme里对这些目录进行依次搜索，对于同一个主题，一旦找到index.theme，就跳出循环。这样的处理就导致了最后bug的出现：系统的多个搜索目录下都存在着 hicolor/index.theme，先找到的仅是后来的一个子集，或者信息不全。比如这里，/opt/gnome/share/icons/hicolor/index.theme和 /opt/kde3/share/icons/hicolor/index.theme都存在，前者是信息完全的，后者没有 48X48/emblems项，不幸的是，/opt/kde3.../index.theme恰恰排在了读取顺序的前列。 这样，仅看/opt/gnome../index.theme无法找到问题所在。
此外，gtk里默认的优先级是先搜索用户目录下的配置文件再搜索系统目录下的配置文件，所以在 ~/.icons/hicolor里添加 index.theme，问题也能够解决。
/opt/kde3/.../index.theme由 kdelibs3-3.5.1-47安装到系统， 而/opt/gnome/../index.theme由gnome-icon-theme-2.12.1-25安装到系统，可以理解两个开发小组对该配置文件有着不同的信息设定需求，并且各自的设置在他们内部测试里都是没有问题的。
最后给出解决方案：
1.修改 kdelibs下的配置文件， 这样最快捷；
2.修改 gtk里的目录搜索策略， 这样的好处是不需要不同开发组的成员进行额外沟通，但是程序整体效率略有问题。
