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 AppImageCommunity/appimaged#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]

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.

AppImageKit/runtime.c

Lines 287 to 358 in 076a88a

	/* ======================================================== Start icon extraction */
	int length;
	char fullpath[FILE_MAX];
	length = readlink("/proc/self/exe", fullpath, sizeof(fullpath));
	fullpath[length] = '\0';
	/* printf("%s\n", fullpath); */
	char theuri[URI_MAX];
	uri_from_filename(fullpath, theuri);
	/* printf("%s\n", theuri); */
	char path_to_thumbnail[URI_MAX];
	char thumbname[URI_MAX];
	thumbname_from_uri(theuri, thumbname);
	sprintf(path_to_thumbnail, "%s%s", thumbnails_medium_dir, thumbname);
	FILE *from, *to;
	char ch;
	char diricon[FILE_MAX];
	sprintf (diricon, "%s/.DirIcon", mount_dir);
	/* open source file */
	if((from = fopen(diricon, "rb"))==NULL) {
	printf("Cannot open %s\n", diricon);
	exit(1);
	}
	/* open destination file */
	char mkcmd[FILE_MAX];
	char iconsdir[FILE_MAX];
	sprintf(mkcmd, "mkdir -p '%s'", thumbnails_medium_dir);
	system(mkcmd);
	if((to = fopen(path_to_thumbnail, "wb"))==NULL) {
	printf("Cannot open %s for writing\n", path_to_thumbnail);
	} else {
	/* copy the file */
	while(!feof(from)) {
	ch = fgetc(from);
	if(ferror(from)) {
	printf("Error reading source file\n");
	exit(1);
	}
	if(!feof(from)) fputc(ch, to);
	if(ferror(to)) {
	printf("Error writing destination file\n");
	exit(1);
	}
	}
	if(fclose(from)==EOF) {
	printf("Error closing source file\n");
	exit(1);
	}
	if(fclose(to)==EOF) {
	printf("Error closing destination file\n");
	exit(1);
	}
	}
	/* If called with --icon, then do not run the main app, just print print a message and exit after extracting the icon */
	char * arg;
	arg=getArg(argc,argv,'-');
	if (arg && strcmp(arg,"icon")==0) {
	printf("Written %s\n", path_to_thumbnail);
	exit(0);
	}
	/* ======================================================== End icon extraction */

[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.

[ahsand97]

I'm still confused, what would be the correct way to have an icon to the .AppImage binary itself?? without requiring to install any kind of daemon, a way that every file manager would show the icon just by downloading the AppImage file

[probonopd]

Either you need a daemon like appimaged from https://github.com/probonopd/go-appimage/, or you need a file manager that natively supports it.

[Sytten]

This is an old issue, but is this the expected behaviours?
I am fine with no icon on the filesystem, but I am wondering if we can set an icon for the dock.

[probonopd]

You can get an icon for the filesystem by using a thumbnailer.
You can get an icon for the Dock by setting the window icon (e.g., QWidget::setWindowIcon() in Qt).

[Sytten]

Yeah I updated tauri to the latest version and it seems to have fixed the issue. Thanks!

[xplshn]

Either you need a daemon like appimaged from https://github.com/probonopd/go-appimage/, or you need a file manager that natively supports it.

@probonopd Would you mind explaining how it works for "a file manager that natively supports it."? I am making a shell-based format that works like AppImages but also like the ape-loader of Cosmopolitan libC. Thanks!