Few weeks ago I have installed LibreOffice from as snap package. Currently I have LibreOffice 7.1.3.2 version.
LibreOffice was working fine. But today I turned on my computer and now for Writer and Calc there are no icons. I pressed the Super key and typed in “libreoffice”. Also this two icons disappeared from dash.
Any idea what has happened or how to fix a problem?
I have solved the problem.
This problem is related to desktop shortcuts I requested for help in another thread and in files:
~/.local/share/applications/libreoffice_calc.desktop
~/.local/share/applications/libreoffice_writer.desktop
I have now notices that I have had “fixed” paths for Icons parameter in them:
/snap/libreoffice/208/usr/share/icons/hicolor/256x256/apps/libreoffice7.1-calc.png
and now when LibreOffice updated to new snap release, new path was created:
/snap/libreoffice/213/usr/share/icons/hicolor/256x256/apps/libreoffice7.1-calc.png
It looks to me that 208 and 213 are snap revision numbers and this revision numbers are not smart to have in any paths, because when new snap revision is released this number changes. Now in first two flies in this post, I have changed the path of Icon parameter to:
/snap/libreoffice/current/usr/share/icons/hicolor/256x256/apps/libreoffice7.1-calc.png
and this solved my problem.
It’s a problem with any .desktop file for snap : they tend to use
/snap/app/**version_number**/some/where
instead of
/snap/app/**current**/some/where
which leads to lose icons every now and then ( ± each time there’s an update for a snap app’ ).
have you filed a bug for this, i don’t think anyone has reported this before (and i can surely not observe it anywhere)
django@ASGARD:~$ grep ^Icon /var/lib/snapd/desktop/applications/*
/var/lib/snapd/desktop/applications/chromium_chromium.desktop:Icon=/snap/chromium/1589/chromium.png
/var/lib/snapd/desktop/applications/gimp_gimp.desktop:Icon=/snap/gimp/367/meta/gui/icon.png
/var/lib/snapd/desktop/applications/sayonara_sayonara.desktop:Icon=/snap/sayonara/123/usr/share/icons/hicolor/256x256/apps/sayonara.png
/var/lib/snapd/desktop/applications/shotcut_shotcut.desktop:Icon=/snap/shotcut/330/meta/gui/shotcut-logo-64.png
/var/lib/snapd/desktop/applications/ubuntu-budgie-welcome_budgie-applets.desktop:Icon=distributor-logo-ubuntu-budgie
/var/lib/snapd/desktop/applications/ubuntu-budgie-welcome_budgie-discourse.desktop:Icon=distributor-logo-ubuntu-budgie
/var/lib/snapd/desktop/applications/ubuntu-budgie-welcome_budgie-themes.desktop:Icon=distributor-logo-ubuntu-budgie
/var/lib/snapd/desktop/applications/ubuntu-budgie-welcome_budgie-welcome.desktop:Icon=distributor-logo-ubuntu-budgie
django@ASGARD:~$
So it may not concern all snap but some target number_version instead of current
Therefore where to report ?
Those .desktop files are ( I guess ) automatically rebuild at each update, to the latest snap number version.
BUT if you are used to copy some .desktop files inside ~/.local/share/applications those won’t be updated, as expected.
What’s not normal is : .desktop files should be « path neutral » by using the provided current symlink.
they hopefully should all target the version number and not current … since the .desktop file is tied to this exact version and is replaced on update/rollback along with the snap so that options in the file as well as the icon, do exactly apply to the running version … this is part of snapds update, install and revert handling since a long time …
using /current is only relevant at all if you manually copy the .desktop file (at your own risk) to ~/.local/share/applications/
Yep. That’s why I amended my bitter comment.
But still I can’t see the interest of targeting number_version since current link exists for the newer version.
That may be a problem for app’s that need data ( things like personal profiles, passwords ) which are not stored under number_version ( maybe this ? )
And that’s not optimal in multi-users context - where all users won’t make use of same app’s / same snap-app’s / same snap-app’s-version. In such a context you need to « tailor » .desktop files at each user’s level.
these .desktop files are generated for every update/rollback, things in the environment stanzas in snapcraft.yaml (or snap/gui or other metadata they get generated from) might have changed, snapd might want/need to add new bits or pieces to the file etc etc … if they were just static files pointing somewhere they could perhaps just use /current … but even then, there are moments where /current does not exist (while being pointed to the new place during upgrade) where you then might hit race conditions …
PS i’m not sure what you mean in the multi user context … if you have multiple versions of the same snap app installed in parallel it will be namespaced …
Mmm. current should always exist then.
Let’s go back to the beginning : icon. Can’t there be a fallback path in the .desktop file : first path is the full absolute « snap » path, second one is just a generic name for the icon ?
i’m not sure what you mean in the multi user context
I mean having on one machine many sessions with very different needs. While trying to keep things clean and organized in each. Snap also adds corner cases here.
its a symlink … you’d have to change the kernels filesystem handling here 
that would be something to ask freedesktop.org about since it would be a change to the XDG spec …
i still dont understand … if you want to use per-user .desktop files because one of your users needs an extra option added for launching, you’d copy the file to ~/.local/share/applications and edit it to have current in there while you add the option …
if you actually mean multiple parallel instances of a snap, you already have to define a namespace when installing the second (or N’th) parallel instance:
Ok I think my limitations in English prevent us from understanding each other, my bad.
I don’t understand why the .desktop files have to target number version ( which is by default the most recent ) since there is already a symlink current which does the same ? What is the risk ? Does not snapd always build that current symlink for each installed and later updated snap ?
If paths inside .desktop files used current instead of number_version it’d be easier to copy those desktop files anywhere needed and…
…then no more need for that editing. Just a little detail. But details matter, and snap already add many details to care about when compared to « legacy » .deb
Parallel installs are another ( interesting ) topic.
Icon= in .desktop file handles one and only one path ? so restrictive, lol.
anyway, to get back on topic, if you actually see icons dissapear for non-hacked (i.e. not manually edited in ~/local/share/applications) .desktop files, there might be a bug in snapd’s generator/snap-install code and you should file it on launchpad …
Problem with icons reappeared after 4 months of displaying fine. Now I see LibreOffice snap was upgraded from 7.1 to 7.2 version and picture file names changed there names. Now I solved the problem by changing Icon parameter path from:
/snap/libreoffice/current/usr/share/icons/hicolor/256x256/apps/libreoffice7.1-calc.png
to
/snap/libreoffice/current/usr/share/icons/hicolor/256x256/apps/libreoffice7.2-calc.png
for Calc and similar for Writer and now icons works again.
I don’t understand why there is a need for having version number in pictures file names if there are only one version of pictures in directory. 
this is really something you have to complain to libreoffice upstream about, not the snaps fault