如何为 Linux 桌面条目文件指定带有相对路径的图标？

发布于 2024-09-13 13:33:34 字数 482 浏览 8 评论 0原文

对于我的一个 Linux 应用程序，我有应用程序二进制文件、一个 launcher.sh 脚本（针对 LD_LIBRARY_PATH）和一个 .desktop 文件，所有这些都位于同一文件夹中。

我想使用图标的相对路径而不是绝对路径。

我已经尝试过：

Icon=app.svg
Icon=./app.svg
Icon=$PWD/app.svg
Icon=$(dirname %k)/app.svg

但这些都不起作用（只有 Icon=/path/to/app.svg）。如果无法指定相对路径并且我必须使用解决方法，我想我可以在每次运行 launcher.sh 脚本时重新生成 .desktop 文件中的图标路径。

最好的方法是什么？使用 sed 或其他一些带有伪正则表达式的替换实用程序，例如 Icon=([valid path chars]+)\n 也许？

原文

For one of my Linux applications, I have the application binary, a launcher.sh script (for the LD_LIBRARY_PATH) and a .desktop file, all in the same folder.

I'd like to use a relative path rather than an absolute path for the icon.

I've tried:

Icon=app.svg
Icon=./app.svg
Icon=$PWD/app.svg
Icon=$(dirname %k)/app.svg

but none of these work (only Icon=/path/to/app.svg). If it's not possible to specify a relative path and I must use a workaround, I was thinking I could regenerate the icon path in the .desktop file every time the launcher.sh script is run.

What would be the best way to do that? Using sed or some other replacement utility with a pseudo-regex like Icon=([valid path chars]+)\n perhaps?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

很糊涂小朋友 2024-09-20 13:33:34

经过更多研究后，据我所知，似乎不可能在桌面条目文件中指定图标的相对路径。

我使用的解决方法是将以下代码添加到 launcher.sh 脚本的末尾：

mv myapp.desktop myapp.desktop-bak
sed -e "s,Icon=.*,Icon=$PWD/app.svg,g" myapp.desktop-bak > myapp.desktop
rm myapp.desktop-bak

这将在每次运行启动器脚本时更新图标的路径，并且由于 .desktop 文件指向启动器脚本，因此单击.desktop 文件有效地更新了其图标。

我知道您可以使用 cat 或 -i 选项来缩短上述代码，但我了解到我使用的解决方案更可靠。如果有人有更多相关信息，请发表评论。

After doing some more research it doesn't look like it's possible to specify relative paths for an icon in a desktop entry file as far as I can see.

The workaround I used was to add the following code to the end of my launcher.sh script:

mv myapp.desktop myapp.desktop-bak
sed -e "s,Icon=.*,Icon=$PWD/app.svg,g" myapp.desktop-bak > myapp.desktop
rm myapp.desktop-bak

This will update the path of the icon each time the launcher script is run, and since the .desktop file points to the launcher script, clicking the .desktop file effectively updates its icon.

I know you could use cat or the -i option to shorten the above code but I've read that the solution I used is more reliable. If anyone has further information on that please do post a comment.

回复收藏 0 原文

鹤舞 2024-09-20 13:33:34

确实，FreeDesktop 规范
不允许相对路径：

标准按键
图标
在文件管理器、菜单等中显示的图标。如果名称是绝对路径，
将使用给定的文件。如果名称不是绝对路径，则
图标主题中描述的算法
规格将是
用于定位图标。
[ 。。。 ]
iconstring类型的值是图标的名称；这些可能是绝对的
使用中描述的算法定位的图标的路径或符号名称
图标主题
规范。这样的
值是用户不可显示的，并且以 UTF-8 编码。

解决方法足够了，
尽管它可能不适用于菜单和面板启动器。
但如果您愿意修补桌面文件
运行 launcher.sh 脚本时，
为什么不实际安装图标？
您可以用两行来完成：

cp app.svg ~/.local/share/icons/hicolor/48x48/apps/
cp app.svg ~/.local/share/icons/hicolor/scalable/apps/

然后放入

Icon=app

桌面文件（app 只是不带文件扩展名的文件名）。

这是定位图标的预期机制
没有绝对路径，
并将确保图标显示在菜单和自定义启动器中。
规范有这样的说法：

那么，您是应用程序作者，并且想要安装应用程序
图标，以便它们在 KDE 和 Gnome 菜单中工作。至少你
应该在 hicolor 主题中安装一个 48x48 图标。这意味着
在 $prefix/share/icons/hicolor/48x48/apps 中安装 PNG 文件。
您可以选择安装不同尺寸的图标。例如，
在 $prefix/share/icons/hicolor/scalable/apps 中安装 svg 图标
意味着大多数桌面都会有一个适用于所有尺寸的图标。

可以做到这一点的一种方法
使用xdg-icon-resource命令，例如

$ xdg-icon-resource install --novendor --context apps --size 48 example-app.png

xdg-icon-resource
不支持 SVG 图像，
实际上，这完成了同样的事情：（

$ cp example-app.svg ~/.local/share/icons/hicolor/48x48/apps/
$ cp example-app.svg ~/.local/share/icons/hicolor/scalable/apps/

这不是拼写错误：将 SVG 文件放在 48x48/apps 文件夹中
菜单和面板将会非常满意。）

对于菜单，最好在安装后更新图标缓存。

$ update-icon-caches ~/.local/share/icons

然后，您可以简单地将 iconstring 指定为 example-app，如下所示：

Icon=example-app

这不是相对路径，
但它解决了必须使用绝对路径的问题
如果桌面文件移动到其他位置也不会中断。

对于它的价值来说，
支持相对路径
在 FreeDesktop 邮件列表上进行了讨论
时间回到 2008 年 9 月：

Magnus Bergmark magnus.bergmark at gmail.com
2008 年太平洋夏令时间 9 月 23 日星期二 01:01:32
[ 。。。 ]
我建议我们也允许以某种方式使用相对路径。
用例
我使用很多 .directory 文件来创建包含电影的目录
将电影海报作为图标。这种行为可以适用于任何形式的
媒体，例如漫画书、音乐（专辑艺术）和照片。
供应商可能希望将图标捆绑到他们正在开发的软件中
分发到 .desktop 文件，该文件不会进入
桌面菜单，因此仍然位于应用程序目录中。

https://lists.freedesktop.org/archives/xdg/2008-September /009940.html

我能找到的唯一反驳
该提案在这里：

.desktop 文件
不打算进入标准应用程序目录的是
几乎完全没用。也许你应该看看一些
软件包建议和实施，并使用
那些，相反。另一个选项是 xdg utils 脚本，用于安装
将 .desktop 文件和图标放在适当的位置。我只能
假设您已卸载的应用程序也打算不遵循
图标主题和图标命名规范。我没有看到
将目录的图标设置为非常有用。设置图标
实际的可执行文件会更有用，尽管 elf 二进制文件确实如此
没有像 win32 二进制文件那样的资源。

https://lists.freedesktop.org/archives/xdg/2008-September /009962.html

相关链接：

It's true that the FreeDesktop specification
does not permit relative paths:

Standard Keys
Icon
Icon to display in file manager, menus, etc. If the name is an absolute path,
the given file will be used. If the name is not an absolute path, the
algorithm described in the Icon Theme
Specification will be
used to locate the icon.
[ . . . ]
Values of type iconstring are the names of icons; these may be absolute
paths, or symbolic names for icons located using the algorithm described in
the Icon Theme
Specification. Such
values are not user-displayable, and are encoded in UTF-8.

The workaround is adequate,
although it probably won't work for menus and panel launchers.
But if you're comfortable patching the desktop file
when running the launcher.sh script,
why not actually install the icon?
You can do it in two lines:

cp app.svg ~/.local/share/icons/hicolor/48x48/apps/
cp app.svg ~/.local/share/icons/hicolor/scalable/apps/

and then put

Icon=app

in the desktop file (app is just the filename without a file extension).

This is the intended mechanism for locating icons
that don't have an absolute path,
and will ensure the icons show up in menus and custom launchers.
The spec has this to say:

So, you're an application author, and want to install application
icons so that they work in the KDE and Gnome menus. Minimally you
should install a 48x48 icon in the hicolor theme. This means
installing a PNG file in $prefix/share/icons/hicolor/48x48/apps.
Optionally you can install icons in different sizes. For example,
installing a svg icon in $prefix/share/icons/hicolor/scalable/apps
means most desktops will have one icon that works for all sizes.

One way this can be done
is with the xdg-icon-resource command, e.g.

$ xdg-icon-resource install --novendor --context apps --size 48 example-app.png

However, xdg-icon-resource
does not support SVG images,
and in practice this accomplishes the same thing:

$ cp example-app.svg ~/.local/share/icons/hicolor/48x48/apps/
$ cp example-app.svg ~/.local/share/icons/hicolor/scalable/apps/

(That's not a typo: put the SVG file in the 48x48/apps folder
and the menus and panels will be perfectly happy.)

For menus, it's a good idea to update the icon cache after installing.

$ update-icon-caches ~/.local/share/icons

Then you can simply give the iconstring as example-app like this:

Icon=example-app

This is not a relative path,
but it solves the problem of having to use an absolute path
and won't break if the desktop file is moved to a different location.

For what it's worth,
support for relative paths
was discussed on the FreeDesktop mailing list
back in September 2008:

Magnus Bergmark magnus.bergmark at gmail.com
Tue Sep 23 01:01:32 PDT 2008
[ . . . ]
I propose that we allow the usage of relative paths in some way also.
Use-cases
I use a lot of .directory files to make directories containing a movie
have the movie poster as the icon. This behaviour could apply to any form of
media, like comic books, music (album art) and photos.
A vendor might want to bundle an icon to a piece of software they're
distributing to go with a .desktop file which are not to go in the
desktop menu and therefore are still located in the application directory.

https://lists.freedesktop.org/archives/xdg/2008-September/009940.html

The only counterargument I was able to find
to this proposal is here:

A .desktop file
that is not intended to go into a standard applications directory is
almost entirely useless. Perhaps you should look at some of the
software bundle proposals and implementations, and work with using
those, instead. Another option is the xdg utils scripts, to install
the .desktop file and icons in the appropriate places. I can only
presume that your uninstalled application also intends to not follow
the Icon Theme and Icon Naming specifications either. And I don't see
setting the directory's icon as useful really. Setting an icon for the
actual executable would be much more useful, though elf binaries do
not have resources like win32 binaries do.

https://lists.freedesktop.org/archives/xdg/2008-September/009962.html