Nach einigen weiteren Recherchen sieht es nicht so aus, als wäre es möglich, relative Pfade für ein Symbol in einer Desktop-Eintragsdatei anzugeben, soweit ich sehen kann.
Die Problemumgehung, die ich verwendet habe, bestand darin, den folgenden Code am Ende meines launcher.sh-Skripts hinzuzufügen:
mv myapp.desktop myapp.desktop-bak
sed -e "s,Icon=.*,Icon=$PWD/app.svg,g" myapp.desktop-bak > myapp.desktop
rm myapp.desktop-bak
Dadurch wird der Pfad des Symbols jedes Mal aktualisiert, wenn das Launcher-Skript ausgeführt wird, und da die .desktop-Datei auf das Launcher-Skript verweist, wird das Symbol durch Klicken auf die .desktop-Datei effektiv aktualisiert.
Ich weiß, dass Sie cat verwenden könnten oder die Option -i, um den obigen Code zu verkürzen, aber ich habe gelesen, dass die von mir verwendete Lösung zuverlässiger ist. Wenn jemand weitere Informationen dazu hat, posten Sie bitte einen Kommentar.
Es stimmt, dass die FreeDesktop-Spezifikation keine relativen Pfade zulässt:
Standardschlüssel
Icon
Symbol zur Anzeige im Dateimanager, in Menüs usw. Wenn der Name ein absoluter Pfad ist, wird die angegebene Datei verwendet. Wenn der Name kein absoluter Pfad ist, wird der in der Icon-Designspezifikation beschriebene Algorithmus verwendet, um das Icon zu lokalisieren.
[ . . . ]
Werte vom Typ iconstring sind die Namen von Symbolen; dies können absolute Pfade oder symbolische Namen für Symbole sein, die unter Verwendung des in der Symboldesign-Spezifikation beschriebenen Algorithmus lokalisiert werden. Solche Werte können nicht vom Benutzer angezeigt werden und sind in UTF-8 codiert.
Die Problemumgehung ist angemessen, obwohl sie wahrscheinlich nicht für Menüs und Panel-Launcher funktioniert. Aber wenn Sie die Desktop-Datei patchen möchten, wenn Sie launcher.sh ausführen Skript, warum nicht das Symbol installieren? Sie können es in zwei Zeilen tun:
cp app.svg ~/.local/share/icons/hicolor/48x48/apps/
cp app.svg ~/.local/share/icons/hicolor/scalable/apps/
und dann setzen
Icon=app
in der Desktop-Datei (app ist nur der Dateiname ohne Dateierweiterung).
Dies ist der beabsichtigte Mechanismus zum Auffinden von Symbolen, die keinen absoluten Pfad haben, und stellt sicher, dass die Symbole in Menüs und benutzerdefinierten Startprogrammen angezeigt werden. Die Spezifikation hat Folgendes zu sagen:
Sie sind also ein Anwendungsautor und möchten Anwendungssymbole so installieren, dass sie in den KDE- und Gnome-Menüs funktionieren. Mindestens sollten Sie ein 48x48-Icon im hicolor-Theme installieren. Dies bedeutet, dass Sie eine PNG-Datei in $prefix/share/icons/hicolor/48x48/apps installieren. Optional können Sie Symbole in verschiedenen Größen installieren. Wenn Sie beispielsweise ein SVG-Symbol in $prefix/share/icons/hicolor/scalable/apps installieren, bedeutet dies, dass die meisten Desktops ein Symbol haben, das für alle Größen funktioniert.
Dies kann zum Beispiel mit xdg-icon-resource geschehen Befehl, z. B.
$ xdg-icon-resource install --novendor --context apps --size 48 example-app.png
Jedoch xdg-icon-resource unterstützt keine SVG-Bilder, was in der Praxis dasselbe bewirkt:
$ cp example-app.svg ~/.local/share/icons/hicolor/48x48/apps/
$ cp example-app.svg ~/.local/share/icons/hicolor/scalable/apps/
(Das ist kein Tippfehler:Legen Sie die SVG-Datei in die Datei 48x48/apps Ordner und die Menüs und Bedienfelder werden vollkommen zufrieden sein.)
Für Menüs ist es eine gute Idee, den Icon-Cache nach der Installation zu aktualisieren.
$ update-icon-caches ~/.local/share/icons
Dann können Sie einfach den iconstring eingeben als example-app so:
Icon=example-app
Dies ist kein relativer Pfad, aber es löst das Problem, einen absoluten Pfad verwenden zu müssen, und wird nicht beschädigt, wenn die Desktop-Datei an einen anderen Ort verschoben wird.
Für das, was es wert ist, wurde die Unterstützung relativer Pfade bereits im September 2008 auf der FreeDesktop-Mailingliste diskutiert:
Magnus Bergmark magnus.bergmark unter gmail.com
Dienstag, 23. September 01:01:32 PDT 2008
[ . . . ]
Ich schlage vor, dass wir auch die Verwendung relativer Pfade in irgendeiner Weise zulassen.
Anwendungsfälle
-
Ich verwende viele .directory-Dateien, um Verzeichnisse, die einen Film enthalten, mit dem Filmplakat als Symbol zu versehen. Dieses Verhalten kann auf alle Arten von Medien wie Comics, Musik (Albumcover) und Fotos zutreffen.
-
Ein Anbieter möchte möglicherweise ein Symbol zu einer Software bündeln, die er weitervertreibt, damit sie zu einer .desktop-Datei passt, die nicht in das Desktop-Menü aufgenommen werden soll und sich daher immer noch im Anwendungsverzeichnis befindet.
https://lists.freedesktop.org/archives/xdg/2008-September/009940.html
Das einzige Gegenargument, das ich zu diesem Vorschlag finden konnte, ist hier:
Eine .desktop-Datei, die nicht in ein Standardanwendungsverzeichnis aufgenommen werden soll, ist fast völlig nutzlos. Vielleicht sollten Sie sich einige der Vorschläge und Implementierungen für Softwarepakete ansehen und stattdessen mit diesen arbeiten. Eine weitere Option sind die xdg utils-Skripte, um die .desktop-Datei und Symbole an den entsprechenden Stellen zu installieren. Ich kann nur vermuten, dass Ihre deinstallierte Anwendung auch beabsichtigt, die Spezifikationen für Symboldesign und Symbolbenennung nicht zu befolgen. Und ich sehe es nicht als sinnvoll an, das Symbol des Verzeichnisses zu setzen. Das Setzen eines Symbols für die eigentliche ausführbare Datei wäre viel nützlicher, obwohl Elf-Binärdateien keine Ressourcen wie Win32-Binärdateien haben.
https://lists.freedesktop.org/archives/xdg/2008-September/009962.html
Verwandte Fragen:
- https://askubuntu.com/questions/277190/how-to-package-an-application-icon-properly
- https://unix.stackexchange.com/questions/404955/gibt-es-einen-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
Relevante Links:
- 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