AppImages on <mntpoint>/Applications have no thumbnails

[probonopd]

AppImags in the read-only /isodevice/Applications/ have no thumbnails. AppImages in $HOME/Downloads do have thumbnails. Why?

appimaged, continuous build (commit 2e34378), build 108 built on 2019-03-14 17:43:20 UTC

Every AppImage processed by libappimage ought to have a thumbnail.

This is on Xubuntu 18.04.

[probonopd]

In fact, in this version no thumbnails get generated at all.

me@host:~$ appimaged --version
appimaged, continuous build (commit 3b794f3), build 86 built on 2019-01-18 04:35:47 UTC

(...)

me@host:~$ find .cache/thumbnails/
.cache/thumbnails/
.cache/thumbnails/normal
.cache/thumbnails/large

[probonopd]

This may partly be caused by https://github.com/AppImage/libappimage/issues/104. After manually installing

sudo apt-get install libglib2.0-dev

I do get some icons. But still not in /isodevice/Applications.

So it's actually two issues:

1. Thumbnails must be created without the user having to install libglib2.0-dev
2. Thumbnails must be created for all locations watched by appimaged

[azubieta]

This issue implies image manipulation which is being addressed at #104

[probonopd]

1. is currently being worked around by https://github.com/AppImage/appimaged/commit/ff7f67377e835df351827eb7e4938505d1b5d389
2. Is what needs to be done. I doubt it has to do with image manipulation?

[azubieta]

Tried the latest build (23a3b00) on Xubuntu 18.04 and it seems fixed. There are still some AppImages that doesn't get their thumbnails but this is provably because packaging issue and not libappimage issues. By example in some cases apps developers user weird icon resolutions which are not accepted by some desktops environments therefore the thumbnail is not created.

Will close the issue, please reopen if required.

[probonopd]

I can confirm that I do see icons in /isodevice/Applications using xubuntu-19.04-desktop-amd64.iso now.

I wonder what's up with the kdenlive-19.04.1c-x86_64.appimage icon though.

[probonopd]

But now icons are missing in $HOME/Downloads.

Please see https://github.com/AppImage/appimaged#monitored-directories for the list of directories which shall be watched (and hence, get icons).

@azubieta

[probonopd]

Killing and launching appimaged manually made the icons appear in $HOME/Downloads. Strange!

[TheAssassin]

Have you tried whether it's the AppImages that have broken icons embedded? Would be useful to see whether there's some demand for additional "fix broken stuff automatically" kind of features in libappimage.

[probonopd]

A quick glance inside the Kdenlive AppDir shows that the correct icons are there, but I did not do a detailed debugging yet. Do we know this fallback icon? Is it coming from us?

[mttbernardini]

If you have interest, I built a thumbnailer for appimages following GNOME (and therefore derivatives) and KDE specs.

Using the thumbnailer removes the responsibility from appimaged/AIL to manually populate the thumbnail cache according to the XDG spec and removes the need to "watch" directories in order to have thumbnails, since the job gets done by the file manager (similarly to how thumbnails are generated for other files), plus it would get more "UNIX philosophy" (one unit of software doing only one thing).

If you want to join effort towards this direction, then this issue would not apply anymore, plus we have the benefit of getting thumbnails anywhere in the file system. Please point out if you notice anything radically different between manual thumbnail cache population (as currently done by libappimage) and my gnome/kde thumbnailing.

PS: there's one issue that I'm not quite sure how to deal with, but I think it also applies for the current libappimage thumbnailing, so there shouldn't be any difference in this regard (correct me if I'm wrong).

[probonopd]

Thank you very much @mttbernardini, I have linked it on https://github.com/AppImage/awesome-appimage/blob/main/README.md#desktop-integration.