为什么 GTK4 似乎只使用 48x48 图标来显示所有上下文中的最小化应用程序?
Why GTK4 seems to use only 48x48 icons for displaying minimized application in all context?
在 GTK4 中,用于显示应用程序的图标系统已更改。
在 GTK3/GTK2 中,我们可以使用简单的命令,例如 gtk_window_set_icon() 或 gtk_window_set_default_icon_from_file() 或 gtk_window_set_icon_list()。
在 GTK4 中这些命令消失了,我们必须使用 Freedesktop Icon Theme Specification 定义的主题系统(也可以在 GTK3 中使用)。在上一个问题中,我已经深入研究了它在实践中的含义:
最后生成的代码非常简单:
icon_theme = gtk_icon_theme_get_for_display (gdk_display_get_default ());
gtk_icon_theme_add_search_path(icon_theme,path_to_my_ressource_directory);
if(gtk_icon_theme_has_icon(icon_theme,"my-icon")!=1)
{
// manage error
}
gtk_window_set_default_icon_name("my-icon"); // default icon for all windows if nothing is set explicitly if I understand well.
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "Your app");
gtk_window_set_icon_name(GTK_WINDOW (window),"my-icon"); // set explicitly the icon for the min window
假设 ressource_directory 是这样定义的:
/ressources$ ls
hicolor icon-theme.cache
cd hicolor/
/ressources/hicolor$ ls
128x128 150x150 192x192 256x256 310x310 48x48 512x512 64x64 72x72 96x96 scalable
/ressources/hicolor$ cd 128x128
/ressources/hicolor/128x128$ ls
apps
/ressources/hicolor/128x128$ cd apps
/ressources/hicolor/128x128/apps$ ls
my-icon.png
它现在可以工作了,当我启动应用程序时,我有我的 wonderfull 图标。
Buuuuuttttt...实际情况是图标模糊不清,而在我的应用程序的 GTK2 版本中却不是。
倒数第一个图标是我在 GTK2 中的应用程序,第二个图标(模糊的)是相同的 GTK4 中的应用程序。
结果是一个模糊的图标。我对图标做了一些测试,似乎 GTK 在 GTK4 的这个上下文中只使用 48x48 图标,当它在其他上下文中使用时会给出一个模糊的图标。
是不是GTK的bug?它与我的桌面环境(这里是 KDE)的交互不好吗?还是我这边的错误?
更重要的是:如何纠正这个令人不满意的结果?
在找到答案之前我不得不进行大量挖掘......它有点模糊。
这是故事:
自从 Freedesktop Icon Theme Specification 出现后,从软件到 Windows 管理器 (WM) 的图标通信就不同了。
据我了解,现在系统将寻找一个“.desktop”文件,该文件必须汇总可执行文件和命名图标之间的 link。然后在目录结构中找到命名图标,就像我问题中的示例一样。主要区别在于它应该位于以下标准化目录之一中:
XDG_DATA_HOME/icons
或 XDG_DATA_DIRS/icons
$HOME/.icons
(为了回溯兼容性,但似乎不是当前的“方式”
XDG_DATA_HOME
在我的系统上似乎是典型的空值,空时的默认值为 $HOME/.local/share
according to the freedesktop specification。
XDG_DATA_DIR
通常不为空,其值如 /usr/share
等。
例如在我的系统上:
echo $XDG_DATA_DIRS
/usr/share/plasma:/home/theuser/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop
如果XDG_DATA_DIR为空,替换为/usr/local/share/:/usr/share/
现在,这在实践中意味着什么?
这意味着在现代世界post-“Freedesktop 规范”中,程序不再直接通知系统它们的图标。在像 Wayland 这样的现代显示协议上,应用程序不再可能与系统通信表示程序使用的图标的像素图。您的应用程序的 .desktop 文件和图标目录现在在这些系统上是必需的。
更重要的是,根据 Gnome with whom I discussed here about the problem.
的开发者,这意味着像 gtk_window_set_icon_name
这样的功能现在只是一种“回退机制”
作为回退机制,它可以被 Windows 管理器忽略。更重要的是:作为一种后备机制,它似乎被 Gnome 开发人员搁置了......它并没有真正对我暴露的错误做出反应,并在使用 .desktop 文件时重定向我。
所以,根据这些信息,我已经这样做来解决问题了:
- 将我的应用程序图标的 hicolor 目录(结构见问题)放在
~/.local/share/icons
- 创建一个包含以下内容的
my_application.desktop
文件:
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Name=myapplication
Exec=PATH_to_my_executable
Comment=blabla
Icon=my-icon
Terminal=false
Categories=Utility;GTK;
- 正在复制
~/.local/share/applications
中的文件
而且有效! (重启后...)
图标不再模糊。
一些附加信息:
直接启动 .desktop 文件和直接启动可执行文件时结果都有效。有趣的是,启动一个与桌面文件中编写的目录不同的类似可执行文件似乎也可以工作。但是我真的不明白这里的魔法。
有人说在图标目录上调用 gtk-update-icon-cache
有助于提高性能,有时是强制性的。我已经在没有注意到变化的情况下进行了测试,并且我在 KDE-based 系统上对这个东西有很大的质疑……(QT 如何管理其缓存?)。它可以帮助在基于 gtk 的系统上保存重启。
可以手动或使用特定命令复制 .desktop 文件:
- desktop-file-validate 验证桌面文件格式是否正确
- desktop-file-install把桌面文件放在good目录下
- update-desktop-database 重建 .desktop 文件的缓存
同样可以使用以下命令自动复制图标:
xdg-desktop-icon
但似乎应该逐个图标使用它,如果您没有脚本来自动执行该操作并且目录已准备就绪,这可能会很慢。
xdg-icon-resource forceupdate
也可以用来避免调用 ``gtk-update-icon-cache`,it seems to encapsulate that and to adapt to the system(也应该在 KDE 系统上工作)并且可能是自动化的好方法system-agnostic 方式。
为了兼容性,我认为保持旧的方式 (gtk_window_set_icon_name) 保持代码与旧系统或 mac/windows 系统兼容仍然是一件好事。
在 GTK4 中,用于显示应用程序的图标系统已更改。
在 GTK3/GTK2 中,我们可以使用简单的命令,例如 gtk_window_set_icon() 或 gtk_window_set_default_icon_from_file() 或 gtk_window_set_icon_list()。
在 GTK4 中这些命令消失了,我们必须使用 Freedesktop Icon Theme Specification 定义的主题系统(也可以在 GTK3 中使用)。在上一个问题中,我已经深入研究了它在实践中的含义:
最后生成的代码非常简单:
icon_theme = gtk_icon_theme_get_for_display (gdk_display_get_default ());
gtk_icon_theme_add_search_path(icon_theme,path_to_my_ressource_directory);
if(gtk_icon_theme_has_icon(icon_theme,"my-icon")!=1)
{
// manage error
}
gtk_window_set_default_icon_name("my-icon"); // default icon for all windows if nothing is set explicitly if I understand well.
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "Your app");
gtk_window_set_icon_name(GTK_WINDOW (window),"my-icon"); // set explicitly the icon for the min window
假设 ressource_directory 是这样定义的:
/ressources$ ls
hicolor icon-theme.cache
cd hicolor/
/ressources/hicolor$ ls
128x128 150x150 192x192 256x256 310x310 48x48 512x512 64x64 72x72 96x96 scalable
/ressources/hicolor$ cd 128x128
/ressources/hicolor/128x128$ ls
apps
/ressources/hicolor/128x128$ cd apps
/ressources/hicolor/128x128/apps$ ls
my-icon.png
它现在可以工作了,当我启动应用程序时,我有我的 wonderfull 图标。
Buuuuuttttt...实际情况是图标模糊不清,而在我的应用程序的 GTK2 版本中却不是。
倒数第一个图标是我在 GTK2 中的应用程序,第二个图标(模糊的)是相同的 GTK4 中的应用程序。
结果是一个模糊的图标。我对图标做了一些测试,似乎 GTK 在 GTK4 的这个上下文中只使用 48x48 图标,当它在其他上下文中使用时会给出一个模糊的图标。
是不是GTK的bug?它与我的桌面环境(这里是 KDE)的交互不好吗?还是我这边的错误?
更重要的是:如何纠正这个令人不满意的结果?
在找到答案之前我不得不进行大量挖掘......它有点模糊。
这是故事:
自从 Freedesktop Icon Theme Specification 出现后,从软件到 Windows 管理器 (WM) 的图标通信就不同了。
据我了解,现在系统将寻找一个“.desktop”文件,该文件必须汇总可执行文件和命名图标之间的 link。然后在目录结构中找到命名图标,就像我问题中的示例一样。主要区别在于它应该位于以下标准化目录之一中:
XDG_DATA_HOME/icons
或XDG_DATA_DIRS/icons
$HOME/.icons
(为了回溯兼容性,但似乎不是当前的“方式”
XDG_DATA_HOME
在我的系统上似乎是典型的空值,空时的默认值为 $HOME/.local/share
according to the freedesktop specification。
XDG_DATA_DIR
通常不为空,其值如 /usr/share
等。
例如在我的系统上:
echo $XDG_DATA_DIRS
/usr/share/plasma:/home/theuser/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop
如果XDG_DATA_DIR为空,替换为/usr/local/share/:/usr/share/
现在,这在实践中意味着什么?
这意味着在现代世界post-“Freedesktop 规范”中,程序不再直接通知系统它们的图标。在像 Wayland 这样的现代显示协议上,应用程序不再可能与系统通信表示程序使用的图标的像素图。您的应用程序的 .desktop 文件和图标目录现在在这些系统上是必需的。
更重要的是,根据 Gnome with whom I discussed here about the problem.
的开发者,这意味着像gtk_window_set_icon_name
这样的功能现在只是一种“回退机制”
作为回退机制,它可以被 Windows 管理器忽略。更重要的是:作为一种后备机制,它似乎被 Gnome 开发人员搁置了......它并没有真正对我暴露的错误做出反应,并在使用 .desktop 文件时重定向我。
所以,根据这些信息,我已经这样做来解决问题了:
- 将我的应用程序图标的 hicolor 目录(结构见问题)放在
~/.local/share/icons
- 创建一个包含以下内容的
my_application.desktop
文件:
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Name=myapplication
Exec=PATH_to_my_executable
Comment=blabla
Icon=my-icon
Terminal=false
Categories=Utility;GTK;
- 正在复制
~/.local/share/applications
中的文件
而且有效! (重启后...)
图标不再模糊。
一些附加信息:
直接启动 .desktop 文件和直接启动可执行文件时结果都有效。有趣的是,启动一个与桌面文件中编写的目录不同的类似可执行文件似乎也可以工作。但是我真的不明白这里的魔法。
有人说在图标目录上调用
gtk-update-icon-cache
有助于提高性能,有时是强制性的。我已经在没有注意到变化的情况下进行了测试,并且我在 KDE-based 系统上对这个东西有很大的质疑……(QT 如何管理其缓存?)。它可以帮助在基于 gtk 的系统上保存重启。可以手动或使用特定命令复制 .desktop 文件:
- desktop-file-validate 验证桌面文件格式是否正确
- desktop-file-install把桌面文件放在good目录下
- update-desktop-database 重建 .desktop 文件的缓存
同样可以使用以下命令自动复制图标: xdg-desktop-icon
但似乎应该逐个图标使用它,如果您没有脚本来自动执行该操作并且目录已准备就绪,这可能会很慢。
xdg-icon-resource forceupdate
也可以用来避免调用 ``gtk-update-icon-cache`,it seems to encapsulate that and to adapt to the system(也应该在 KDE 系统上工作)并且可能是自动化的好方法system-agnostic 方式。
为了兼容性,我认为保持旧的方式 (gtk_window_set_icon_name) 保持代码与旧系统或 mac/windows 系统兼容仍然是一件好事。