Appimagekit: How to set icon for AppImage binary itself ??

[keshavbhatt]

I created appimage of my two applications , both of them don't show thumbnail/icon for by their self
am i missing something ???

I also seen that filefox appimage also unable to show thumbnail/icon or itself while corebird appimage do.

[probonopd]

This functionality was available as part of runtime.c for type 1 AppImages but it was a dirty hack not fully implementing the thumbnail spec and has been removed in favor of the optional appimaged daemon. Writing a proper full-blown AppImage thumbnailer or implementing the whole protocol in appimaged would be the solution; pull requests welcome.

[chrisnharvey]

Will this feature ever return? I personally recommend AppImages to people, for the primary reason that they can be downloaded and run without any additional tools (like appimaged). So if a user has a directory full of AppImages (like I do on several machines that do not run appimaged), then it is quite annoying for all of these apps to have the same icon.

[probonopd]

It might come back if someone (= not me) implements the the whole full-blown Thumbnail Managing Standard in the AppImage runtime. Pull requests welcome.

[teras]

Are you sure thumbnails are for files other than images?
I think nautilus uses the gio set metadata::custom-icon instead

[probonopd]

@teras you are right. So if we can implement it "in the right way", even better! But let's keep in mind that this a) must not add heavy dependencies to AppRun.c (pure C) and must work on KDE, XFCE, Deepin, etc. too.

[teras]

@probonopd I don't have any idea how it is on other desktop systems, and there could be millions of them :) Indeed the support should be global, but how?

[probonopd]

The XDG Thumbnailer spec is implemented by every desktop. So as long as we use it we should be fine.

[azubieta]

WIP at #578

[TheAssassin]

The thumbnailer code has been merged. It just has to be implemented properly in the runtime. CC @probonopd

[probonopd]

It just has to be implemented properly in the runtime.

Do we still plan to do that? I think we should...

[TheAssassin]

I don't think our plans on that have changed. We just need someone to do it.

[azubieta]

Now we have a thumbnailers for gnome, kde and the default XDG thumbnails implementation. Therefore we can close the issue.

[probonopd]

@azubieta do we also have the feature that when no thumbnailer is installed, than merely running the app will put the thumbnail icon into the place specified by the XDG thumbnail spec?

We had this a while ago (for type-1 images) and seemingly people liked it.

[azubieta]

The runtime is already linked to libappimage so it could be implemented. I just don't like the idea of adding more stuff to the runtime.

[probonopd]

The runtime is already linked to libappimage

I was not really aware of that... why have we done this?

I just don't like the idea of adding more stuff to the runtime.

Agree, I am also a bit hesitant for the same reason. Also, it's a workaround rather than a proper solution in the sense of https://github.com/AppImage/appimaged/issues/30

[develar]

@azubieta Ouch, it is incredible cool and useful, so, it is part of new runtime (sorry, do not see commit reference here)?

[probonopd]

@develar please have a look at https://github.com/AppImage/appimaged/issues/30 - is this an area in which you would be interested enough to join a broader discussion and specification effort, e.g., on opendesktop.org? We want to get how applications can be integrated dynamically into the desktop "right" this time, and increasingly I think we cannot do it alone (as the AppImage project)

[TheAssassin]

The runtime isn't linked to libappimage, but to one of it's modules that contains the functionality shared between libappimage (and anything that links to it) and AppImageKit (runtime, appimagetool etc.).
This was done due to the bad structure in the original source code, and it's by far the most elegant way to do it right now.

IIRC the XDG thumbnailing stuff is performed by the runtime on every startup already. That covers most desktop environments (among the big players, only KDE doesn't support that spec).

@azubieta would appreciate if you could look for the line in the code base where that thumbnailer is run. IIRC you implemented that ~ 1 year ago.

[ChristianCiach]

Today I stumbled upon this project and AppImages in general while investigating how we could deploy our app. After downloading some AppImages from the Hub, I noticed that some of them got an icon for their .AppImage-file after launching, but most did not.

As I understand it, this feature was removed from AppImageKit and users now need a running appimaged to get this functionality.

In my opinion, this is a huge step backwards. I think the main feature of AppImages is that they are completely standalone. Asking our users to install some daemon that is not even in the repos of any major linux distribution is a no-go. As I see it, there is not even a single tagged version of appimaged, just continuous builds (and the current one even crashes with a segmentation fault).

This sounded probably a lot harsher than I intended it to, and for this i apologize. I love the concept of AppImages and will probably deploy our software this way. It's just a bummer that the users have to deal with the default binary-file icon of their file browser, instead of a nice icon that is packaged with our AppImage (but that will never be seen by the users).

I sincerely hope that this feature will return without the need to force a daemon on our users!

[ChristianCiach]

Quick and dirty workaround:

Assume your mycoolapp.desktop file launches a shellscript called start.sh:

[Desktop Entry]
Name=MyCoolApp
Exec=start.sh %F

Then you can put this into your start.sh:

#!/bin/bash

if [ ! -z "$APPIMAGE" ] && [ ! -z "$APPDIR" ]; then
    MD5=$(echo -n "file://$APPIMAGE" | md5sum | cut -d' ' -f1)
    cp "$APPDIR/usr/share/icons/hicolor/128x128/apps/mycoolapp.png" "$HOME/.cache/thumbnails/normal/$MD5.png"
    cp "$APPDIR/usr/share/icons/hicolor/256x256/apps/mycoolapp.png" "$HOME/.cache/thumbnails/large/$MD5.png"
    xdg-icon-resource forceupdate
fi

# Now start your actual app...

Adjust as necessary :) You do not need to provide image files for multiple resolutions. We only provide a single 256x256 icon that I copy to "$HOME/.cache/thumbnails/large/" and it works just fine.

[probonopd]

Asking our users to install some daemon that is not even in the repos of any major linux distribution is a no-go.

It comes as an AppImage...

[ChristianCiach]

It comes as an AppImage...

I realize that. But in my opinion, the people that benefit from AppImages the most are also the people that do not know how to open a shell and install a daemon from the command line :) This is something I strongly belief should not be required from the average user to enjoy AppImages at their best.

[probonopd]

Quick and dirty workaround

I think this only implements parts of the XDG Thumbnail Managing Standard and may even fail e.g., on KDE Plasma which will only show thumbnails for which it knows the thumbnailer that generated them... also those thumbnails are missing the metadata (5.2. Thumbnail Attributes).

[probonopd]

people that benefit from AppImages the most are also the people that do not know how to open a shell and install a daemon from the command line :)

Indeed, we should have a GUI installer...

[ChristianCiach]

I think this only implements parts of the XDG Thumbnail Managing Standard and may even fail e.g., on KDE Plasma which will only show thumbnails for which it knows the thumbnailer that generated them... also those thumbnails are missing the metadata (5.2. Thumbnail Attributes).

You are surely right about that, but it is good enough for our internal use cases.

[probonopd]

It's basically why we removed it from runtime.c. If someone comes up with a (tiny) full implementation we might add it back to runtime.c.

https://github.com/AppImage/AppImageKit/blob/076a88a57d7ca1a8d77bdbf7d8e92f37eea03dab/runtime.c#L287-L358

[ChristianCiach]

Indeed, we should have a GUI installer...

This surely would make things a lot easier! I do not know if appimaged updates itself, but i think this should also be a requirement.

I really hope that appimaged or something like that will someday be part of every major linux distribution :)

[probonopd]

Most traditional distributions are opposed to the AppImage concept because it means that users don't go the distribution for applications, only for the base system.

[ChristianCiach]

It's basically why we removed it from runtime.c

Actually, this is exactly the code I learned from how to do this :) I didn't know about the XDG thumbnailing mechanics before.

Well, I will stop spamming now and will go to bed instead. I am happy with my improvised solution, even if it only works with GTK-based desktop environments. Maybe it helps someone.

I am in the fortunate situation that my app will only be distributed inside our company, so I know that all users are using Gnome shell or XFCE (and for all other users, it won't change anything anyway). Of course, sometime in the future I will surely build such an app for the public, so I will keep my eyes on this issue :) Thank you for your hard work!

[mnesarco]

Hi Friends,
As a workaround, I have created a linuxdeploy plugin to do the xdg thumbnail trick based on @ChristianCiach comment.

The plugin is a simple bash script:
https://gist.github.com/mnesarco/6e5712ef836bfdd330178ff2bc9be54c

It adds a hook to generate the thumbnail.

Example usage:

export XDG_ICON=/path/to/my/png/icon
linuxdeploy --appdir=[...] -d [...] -i [...] --plugin xdg --output appimage

[probonopd]

Thanks @mnesarco. Just be aware that only copying a icon file is not sufficient as per the dreaded XDG Thumbnail Spec, you also need to have certain metadata ("Thumbnail Attributes") stored in a byzantine format (no, they are not using xattrs) inside the png.

[mnesarco]

Thanks @probonopd , yes you are absolutely right. The XDG Thumbnail Spec is so weird, so much that file managers ignore the metadata :D. I was looking desesperately to a solution to set the icon without resorting to installing any daemon. So I tested the @ChristianCiach solution and it worked only to show AppImage with the icon in the file manager, it does not work for example to show the icon on the dock when launched. So I have resorted to another approach:

Now I have created a script to transform the AppImage file into a shell script that "installs" the AppImage and set the icon and launcher in $HOME/.local/shared/icons and $HOME/.local/shared/applications. It works better, and the icon is ok on the dock too. It is an independent script so it can be used for anyone who likes this approach:

https://gist.github.com/mnesarco/baa2d49d9ec1b1edb41be7202cac352d

The generated installer script is 100% self-contained. So the final user still downloads a single file.