Después de investigar un poco más, no parece que sea posible especificar rutas relativas para un ícono en un archivo de entrada de escritorio por lo que puedo ver.
La solución que utilicé fue agregar el siguiente código al final de mi secuencia de comandos 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
Esto actualizará la ruta del ícono cada vez que se ejecute la secuencia de comandos del iniciador, y dado que el archivo .desktop apunta a la secuencia de comandos del iniciador, hacer clic en el archivo .desktop efectivamente actualiza su ícono.
Sé que podrías usar cat o la opción -i para acortar el código anterior, pero he leído que la solución que utilicé es más confiable. Si alguien tiene más información al respecto, publique un comentario.
Es cierto que la especificación FreeDesktop no permite rutas relativas:
Teclas estándar
Icon
Icono para mostrar en el administrador de archivos, menús, etc. Si el nombre es una ruta absoluta, se usará el archivo dado. Si el nombre no es una ruta absoluta, se utilizará el algoritmo descrito en Icon ThemeSpecification para ubicar el icono.
[ . . . ]
Valores de tipo iconstring son los nombres de los iconos; estos pueden ser rutas absolutas o nombres simbólicos para íconos ubicados usando el algoritmo descrito en la Especificación de tema de ícono. Dichos valores no son visualizables por el usuario y están codificados en UTF-8.
La solución alternativa es adecuada, aunque probablemente no funcione para menús y lanzadores de paneles. Pero si se siente cómodo parcheando el archivo de escritorio cuando ejecuta launcher.sh script, ¿por qué no instalar el ícono? Puede hacerlo en dos líneas:
cp app.svg ~/.local/share/icons/hicolor/48x48/apps/
cp app.svg ~/.local/share/icons/hicolor/scalable/apps/
y luego poner
Icon=app
en el archivo de escritorio (app es solo el nombre del archivo sin una extensión de archivo).
Este es el mecanismo previsto para ubicar íconos que no tienen una ruta absoluta y garantizará que los íconos se muestren en menús y lanzadores personalizados. La especificación dice lo siguiente:
Por lo tanto, usted es un autor de aplicaciones y desea instalar íconos de aplicaciones para que funcionen en los menús de KDE y Gnome. Como mínimo, debe instalar un icono de 48x48 en el tema hicolor. Esto significa instalar un archivo PNG en $prefix/share/icons/hicolor/48x48/apps. Opcionalmente, puede instalar íconos en diferentes tamaños. Por ejemplo, instalar un ícono svg en $prefix/share/icons/hicolor/scalable/apps significa que la mayoría de los escritorios tendrán un ícono que funciona para todos los tamaños.
Una forma de hacerlo es con el xdg-icon-resource comando, por ejemplo,
$ xdg-icon-resource install --novendor --context apps --size 48 example-app.png
Sin embargo, xdg-icon-resource no admite imágenes SVG y, en la práctica, esto logra lo mismo:
$ cp example-app.svg ~/.local/share/icons/hicolor/48x48/apps/
$ cp example-app.svg ~/.local/share/icons/hicolor/scalable/apps/
(Eso no es un error tipográfico:coloque el archivo SVG en el 48x48/apps carpeta y los menús y paneles serán perfectamente felices.)
Para los menús, es una buena idea actualizar el caché de iconos después de la instalación.
$ update-icon-caches ~/.local/share/icons
Entonces simplemente puede dar el iconstring como example-app así:
Icon=example-app
Esta no es una ruta relativa, pero resuelve el problema de tener que usar una ruta absoluta y no se romperá si el archivo del escritorio se mueve a una ubicación diferente.
Por si sirve de algo, la compatibilidad con rutas relativas se discutió en la lista de correo de FreeDesktop en septiembre de 2008:
Magnus Bergmark magnus.bergmark en gmail.com
Martes 23 de septiembre 01:01:32 PDT 2008
[ . . . ]
Propongo que también permitamos el uso de rutas relativas de alguna manera.
Casos de uso
-
Utilizo muchos archivos .directory para crear directorios que contengan una película con el cartel de la película como icono. Este comportamiento podría aplicarse a cualquier forma de medio, como cómics, música (carátulas de álbumes) y fotos.
-
Es posible que un proveedor quiera incluir un ícono en una pieza de software que está distribuyendo para que vaya con un archivo .desktop que no debe ir en el menú del escritorio y, por lo tanto, aún se encuentra en el directorio de la aplicación.
https://lists.freedesktop.org/archives/xdg/2008-September/009940.html
El único contraargumento que pude encontrar a esta propuesta está aquí:
Un archivo .desktop que no está destinado a entrar en un directorio de aplicaciones estándar es casi completamente inútil. Tal vez debería mirar algunas de las propuestas e implementaciones de paquetes de software y trabajar con ellas en su lugar. Otra opción son los scripts xdg utils, para instalar el archivo .desktop y los íconos en los lugares apropiados. Solo puedo suponer que su aplicación desinstalada también tiene la intención de no seguir las especificaciones de Icon Theme y Icon Naming. Y no veo que configurar el ícono del directorio sea realmente útil. Establecer un ícono para el ejecutable real sería mucho más útil, aunque los binarios elf no tienen recursos como los binarios win32.
https://lists.freedesktop.org/archives/xdg/2008-September/009962.html
Preguntas relacionadas:
- https://askubuntu.com/questions/277190/how-to-package-an-application-icon-correctamente
- https://unix.stackexchange.com/questions/404955/existe-una-ubicación-del-directorio-principal-para-superar-los-iconos
- https://unix.stackexchange.com/questions/428992/por-que-hacer-freedesktop-desktop-files-not-allow-relative-paths
- https://unix.stackexchange.com/questions/585997/assign-an-icon-to-a-custom-mimetype
Enlaces relevantes:
- https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/82
- https://bugs.kde.org/show_bug.cgi?id=68507
- https://bugs.kde.org/show_bug.cgi?id=73463
- https://lists.freedesktop.org/archives/xdg/2008-September/009940.html
- https://lists.freedesktop.org/archives/xdg/2011-April/011883.html
- https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html