Support for multiple size variants of the representive icon

[kossebau]

Currently the spec has:

• MAY contain an $APPNAME.png file in its root directory with $APPNAME being the name of the payload application as set in the Icon= key of the $APPNAME.desktop file. If present, this icon SHOULD be given preference as the icon being used to represent the AppImage. The icon SHOULD be a PNG with 256x256 or 512x512 pixels

If a pre-rendered-pixels icon should be used, it might be nice to support also multiple sizes of such icons, with variants as suited for needs with smaller icon sizes (less details/colors, different alignment of content to pixels).

Similar to what macOS and Windows have with a single file bundling different versions of an icon (macOS ICNS format, Windows ICO format), such variants are also supported by the xdg Icon Theme specification, though as unbundled separate files, distributed over a directory structure to find certain sizes.

As applications following the xdg Icon Theme spec are usually installing app icon files to "usr/share/icons/hicolor/", it might be an idea to rely on those directories (and possibly even their non-hicolor-theme variants) to get the app icon of a suiting size (and theme), instead of a single (PNG) file in the root of the app dir. The look-up of the file in the root dir could be kept as deprecated backward-compatible fallback in the spec, if no matching icon files are found in the "usr/share/icons" directories.

Relying on metadata (one could see the app icon as such) in their usual "usr/share" folders is already done with the AppStream metadata, so this would not be a new concept in the spec (possibly the same could be also done for the desktop file, where one would first look in the "usr/share/applications" for a single desktop file, before falling back to looking for one in the root of the app dir).

[probonopd]

As per the ROX AppDir specification, exactly one file shall be used as the .DirIcon. It is very unfortunate that on the X Desktop we don't have multi-resolution icons like the other two desktop OSes mentioned. Personally I find the XDG icon spec way convoluted and overly complex. Hence the AppImage tools currently use the one icon that is at the top-level of the directory and copy/symlink that to .DirIcon. Note well that the AppDir specification does not assume that there is a usr/share hierarchy inside the AppDir. It is a mere (practical) coincidence that most AppDirs used for AppImages do.

If we ever wrote our own additions to the ROX AppDir specification, then we might mandate something like a usr/share hierarchy, and use the icons from there.

In the meantime, if usr/share/icons/hicolor/<standard_resolution_sizes>/apps/<appname>.xxx then these will be integrated by system integration tools like the optional appimaged daemon and will be picked up from there by the system to build the menus, etc., but again, this is all merely optional.

Does this already cover your use case? In which situations you think the current system is insufficient?

[kossebau]

Thanks for the quick reply :)

My need is that I would like something in the written specification that I/people can rely on when creating appdirs/appimages or when writing software to handle appdirs/appimages. So whatever current code of appimaged & Co. does makes me feel personally not so safe to rely on, as I would not know what is a current hack to get things working for a start and what is long-term targetted by design :)

The current motivation is that I have been looking at the kdevelop appimage together with the KDE/KIO thumbnailer plugin for appimages. The KDevelop appimage had a 48x48px icon used for the .DirIcon (now changed to 256x256), so the thumbnail done from the .DirIcon looked not so nice when asking for larger sizes (and would be worse on HiDpi screens). That reminded me of the issue that one pixel image does not serve for all cases. Even with SVG there are sometimes variants to prepare for small-pixel-size rendering (less details & pixel-grid-aligning adaptions).

So I am looking at this from both appimage creator and consumer side: Wanting to have the (kdevelop) appimage provide all possible content to allow best-quality rendered representative icons (both for system integration & appimage instance display). Wanting to know what content the appimage thumbnailer should/could check to get an image for the target size display.

I was proposing to reuse in the specification the content from usr/share/icons following the XDG icon spec, as this means no additional things have to be done when creating appimage for many of existing linux applications, as they already install their icons to those path following the spec. So it would be just the appimage consumers which would have to be extended to take those icon resources into account. libappimage could provide some util methods to simplify that. If we would read from multi-resolution icons, we would also use some 3rd-party library to help with the icons format anyway.

When it comes to .DirIcon, I understand you want to not reinvent whole specs and instead have some continuity from other specs. Though for this very file, I wonder if it worth it:

• .DirIcon naming is inconsistent with the other metadata/description file, $APPNAME.desktop: one is a hidden file with a generic name, given there should be only one anyway, the other is not hidden and has some random basename, while there also should only be one of that kind
• as by current spec text, it SHOULD be a PNG with 256x256 or 512x512 pixels, where a single pixel image does not serve all cases (and a single SVG also would not be the silver-bullet as noted above)

on the X Desktop we don't have multi-resolution icons

We have, it just that they are not done by single-file bundle (say IconImage ;) ) with an format-internal "filesystem" to pick a matching image variant, but instead the image variants are distributed directly on the normal system filesystem, with the XDG Icon spec describing the overlayed logic how to pick the matching image variant :) With some added complexity for other use-cases like theming, which many people prefer to have.

[probonopd]

Thanks @kossebau. I understand that you are looking for an updated and concise AppDir spec. The complication is that we are trying to stay compliant to the ROX AppDir spec, whereas we have factually (by convention, not by spec) extended/specialized the format a bit (and still, like you point out, have to do some things that are not ideal).

We could say "screw it, let's write an AppDir 2.0 spec". But even then I am not sure we would be doing the right thing, since the whole XDG system seems to be built around the idea that applications are statically installed on a system, not something that can dynamically come and go (like, say, WLAN connections). Hence I am thinking about how to learn from Mac OS X how to suck less at system integration.. Maybe we need to rethink some of the way applications interact with the desktop altogether. Since you seem to be sincerely interested in this topic, I would like to encourage you to read the linked issue and watch the WWDC videos linked there. I'd be highly interested in what you think about it.

Let's then discuss the best course of action.

Again, thanks for being rigorous, persistent, and precise. If we have not formally specified certain things then it's mostly because we were not sure, and were still experimenting ourselves.

[kossebau]

I am trying to not propose screwing the current spec, but to evolve it, by adding new options and mark then old ones as deprecated, staying backwards-compatible (for now). Especially given that some implementation already assumes certain files to possibly exist and being usable, like appimaged does with usr/share/icons for system integration, while the existing spec is not defining their existence. So appimage creators only looking at the spec have no idea such icons would even be used and as result might leave them out of their appimage to save size, resulting in lower quality on sysmte integration when better would have been possible. As well as could thumbnailer start to do as appimaged does and also try to make use of usr/share/icons where feasible to get better content for needed sizes.

For a complete (re)thinking of application bundle integration with the system I sadly have not enough time left currently as would be needed for meaningful contributions. So I have to stick for now trying to polish what exist and is used now :)

[probonopd]

Which wording would you propose for the spec @kossebau?

[kossebau]

Something like proposed in #20 (first quick draft, could see some rewording possibly)

[probonopd]

Thanks @kossebau

[TheAssassin]

Closing as resolved, thanks @kossebau.