Right now the gnome thumbnailer is installed to /usr/bin/appimage-thumbnailer, no matter the architecture. This makes different arch versions of the package conflicting with each other (moreover this would be silently ignored by apt since the Conflicts clause is not yet defined).

The same goes for the kde thumbnailer, which for some reason is installed to /usr/lib/plugins/libappimage-thumbnailer.so instead of /usr/lib/x86_64-linux-gnu/qt5/plugins/libappimage-thumbnailer.so, even thought I'm using the recommended cmake variable KDE_INSTALL_PLUGINDIR. (partially fixed in 014ab3f)

For now we can assume that no one is willing to install multi-arch packages at the same time, but eventually this issue will need to be tackled.

Now that we are working on support for FreeBSD to use AppImages originally made for Linux, it would be nice to get the thumbnailer to run there, too.

Trying to compile this thumbnailer on FreeBSD leads to:

sed: 1: "configure": command c expects \ followed by text

Similar:
https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux

find . -type file -exec sed -i -e "s|sed -e|sed -i'' -e|g" {} \;

results in a failure with another symptom.

Blocked by:
AppImageCommunity/libappimage#149

In the gnome thumbnailing system, the requested size for a thumbnail is passed with the %s placeholder (see /resources/appimage-thumbnailer.thumbnailer). The gnome thumbnailer should honor the argument and resize .DirIcon to the requested size.

In the kde thumbnailing system, the requested size for a thumbnail is passed with arguments witdht and height. QImage provides a method (scaled) for resizing the icon.

In order to avoid the frame we need to cap the max size to 127px (or actually 52px to make the icon have the same size of native mime-icons).

This approach, however, has the drawback of affecting the image quality. I don't know if there's any other alternative, since the "framing" seems to be hardcoded:

https://github.com/linuxmint/nemo/blob/7fe83632eca5801a55992dc08c52767b6d8685cb/libnemo-private/nemo-file.c#L4817-L4820

Therefore, for now I will mark this issue as "wontfix".