Après avoir fait quelques recherches supplémentaires, il ne semble pas possible de spécifier des chemins relatifs pour une icône dans un fichier d'entrée de bureau pour autant que je sache.
La solution de contournement que j'ai utilisée consistait à ajouter le code suivant à la fin de mon script 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
Cela mettra à jour le chemin de l'icône à chaque exécution du script de lancement, et puisque le fichier .desktop pointe vers le script de lancement, cliquer sur le fichier .desktop met effectivement à jour son icône.
Je sais que vous pourriez utiliser cat ou l'option -i pour raccourcir le code ci-dessus mais j'ai lu que la solution que j'ai utilisée est plus fiable. Si quelqu'un a plus d'informations à ce sujet, merci de poster un commentaire.
Il est vrai que la spécification FreeDesktop n'autorise pas les chemins relatifs :
Clés standard
IconIcône à afficher dans le gestionnaire de fichiers, les menus, etc. Si le nom est un chemin absolu, le fichier donné sera utilisé. Si le nom n'est pas un chemin absolu, l'algorithme décrit dans la spécification du thème d'icône sera utilisé pour localiser l'icône.
[ . . . ]
Valeurs de type
iconstringsont les noms des icônes ; il peut s'agir de chemins absolus ou de noms symboliques d'icônes localisés à l'aide de l'algorithme décrit dans la spécification de thème d'icône. Ces valeurs ne sont pas affichables par l'utilisateur et sont encodées en UTF-8.
La solution de contournement est adéquate, bien qu'elle ne fonctionnera probablement pas pour les menus et les lanceurs de panneaux. Mais si vous êtes à l'aise pour corriger le fichier de bureau lors de l'exécution du launcher.sh script, pourquoi ne pas installer l'icône ? Vous pouvez le faire en deux lignes :
cp app.svg ~/.local/share/icons/hicolor/48x48/apps/
cp app.svg ~/.local/share/icons/hicolor/scalable/apps/
puis mettre
Icon=app
dans le fichier desktop (app est juste le nom du fichier sans extension de fichier).
Il s'agit du mécanisme prévu pour localiser les icônes qui n'ont pas de chemin absolu et garantira que les icônes s'affichent dans les menus et les lanceurs personnalisés. La spécification indique ceci :
Donc, vous êtes un auteur d'applications et vous souhaitez installer des icônes d'application afin qu'elles fonctionnent dans les menus KDE et Gnome. Au minimum, vous devez installer une icône 48x48 dans le thème hicolor. Cela signifie installer un fichier PNG dans $prefix/share/icons/hicolor/48x48/apps. Vous pouvez éventuellement installer des icônes de différentes tailles. Par exemple, l'installation d'une icône svg dans $prefix/share/icons/hicolor/scalable/apps signifie que la plupart des ordinateurs de bureau auront une icône qui fonctionne pour toutes les tailles.
Une façon d'y parvenir est d'utiliser le xdg-icon-resource commande, par exemple
$ xdg-icon-resource install --novendor --context apps --size 48 example-app.png
Cependant, xdg-icon-resource ne prend pas en charge les images SVG, et en pratique cela accomplit la même chose :
$ cp example-app.svg ~/.local/share/icons/hicolor/48x48/apps/
$ cp example-app.svg ~/.local/share/icons/hicolor/scalable/apps/
(Ce n'est pas une faute de frappe :mettez le fichier SVG dans le 48x48/apps dossier et les menus et panneaux seront parfaitement heureux.)
Pour les menus, c'est une bonne idée de mettre à jour le cache des icônes après l'installation.
$ update-icon-caches ~/.local/share/icons
Ensuite, vous pouvez simplement donner le iconstring comme example-app comme ceci :
Icon=example-app
Ce n'est pas un chemin relatif, mais cela résout le problème d'avoir à utiliser un chemin absolu et ne cassera pas si le fichier du bureau est déplacé vers un autre emplacement.
Pour ce que ça vaut, la prise en charge des chemins relatifs a été discutée sur la liste de diffusion FreeDesktop en septembre 2008 :
Magnus Bergmark magnus.bergmark sur gmail.com
mar 23 septembre 01:01:32 PDT 2008
[ . . . ]
Je propose que nous autorisions également l'utilisation de chemins relatifs d'une manière ou d'une autre.
Cas d'utilisation
J'utilise beaucoup de fichiers .directory pour créer des répertoires contenant un film avec l'affiche du film comme icône. Ce comportement peut s'appliquer à toute forme de média, comme les bandes dessinées, la musique (pochette d'album) et les photos.
Un fournisseur peut vouloir regrouper une icône à un logiciel qu'il redistribue pour aller avec un fichier .desktop qui ne doit pas aller dans le menu du bureau et se trouve donc toujours dans le répertoire de l'application.
https://lists.freedesktop.org/archives/xdg/2008-September/009940.html
Le seul contre-argument que j'ai pu trouver à cette proposition est ici :
Un fichier .desktop qui n'est pas destiné à aller dans un répertoire d'applications standard est presque totalement inutile. Peut-être devriez-vous examiner certaines des propositions et implémentations de bundles logiciels et travailler avec celles-ci à la place. Une autre option est les scripts d'utilitaires xdg, pour installer le fichier .desktop et les icônes aux endroits appropriés. Je ne peux que présumer que votre application désinstallée a également l'intention de ne pas suivre les spécifications de thème d'icône et de nommage d'icône non plus. Et je ne vois pas vraiment comment définir l'icône du répertoire comme utile. Définir une icône pour l'exécutable réel serait beaucoup plus utile, bien que les binaires elf n'aient pas de ressources comme les binaires win32.
https://lists.freedesktop.org/archives/xdg/2008-September/009962.html
Questions connexes :
- https://askubuntu.com/questions/277190/how-to-package-an-application-icon-properly
- https://unix.stackexchange.com/questions/404955/is-there-a-home-directory-location-for-overriding-icons
- https://unix.stackexchange.com/questions/428992/why-do-freedesktop-desktop-files-not-allow-relative-paths
- https://unix.stackexchange.com/questions/585997/assign-an-icon-to-a-custom-mimetype
Liens pertinents :
- 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