Handle AppImages with non-standard icon sizes more gracefully

[probonopd]

The PrusaSlicer-2.0.0-rc2+linux64-201905190649.AppImage icon does not show up in the menu.

libappimage extracts it to

me@host:~/Desktop$ find .. | grep appimagekit_bbb83c4af999fd7bc368a2c557abcb95_PrusaSlicer
../.local/share/icons/hicolor/154x154/apps/appimagekit_bbb83c4af999fd7bc368a2c557abcb95_PrusaSlicer.png

Of course, .local/share/icons/hicolor/154x154/apps/ is not a valid location.

me@host:~/Desktop$ /isodevice/Applications/PrusaSlicer-2.0.0-rc2+linux64-201905190649.AppImage --appimage-extract '*PrusaSlicer.png'
squashfs-root/PrusaSlicer.png
me@host:~/Desktop$ /isodevice/Applications/PrusaSlicer-2.0.0-rc2+linux64-201905190649.AppImage --appimage-extract '*.png'
squashfs-root/PrusaSlicer.png
me@host:~/Desktop$ file squashfs-root/PrusaSlicer.png 
squashfs-root/PrusaSlicer.png: PNG image data, 154 x 154, 8-bit/color RGBA, non-interlaced
me@host:~/Desktop$ /isodevice/Applications/PrusaSlicer-2.0.0-rc2+linux64-201905190649.AppImage --appimage-extract '.DirIcon'
squashfs-root/.DirIcon
me@host:~/Desktop$ file squashfs-root/.DirIcon 
squashfs-root/.DirIcon: symbolic link to PrusaSlicer.png

Question #1: Why didn't it resize the icon to one of the proper sizes?
Question #2: If it cannot resize the icon to one of the proper sizes, why didn't it at least put it into one of the standard icon locations, e.g., 128x128?

cc @azubieta

[azubieta]

If the icon is a valid png file and libpng is installed it should be resized and placed in the right folder properly. If libcairo (which uses libpng) fails to load the file we aren't able to get any information form the file therefore it will have to be just dropped into a well know location.

Provably what we are seen here is a bug on libcairo or libpng. I will investigate this.

[TheAssassin]

There is no well known location: Icons in the wrong directory won't be displayed.

We shouldn't be responsible for fixing the app author's failures. They can check whether they did it right with appimagelint.

The only viable workaround I'd implement is, if there's no usr/share/icons, use .DirIcon. And .DirIcon then needs to be copied into all standard sizes icon theme locations. If it is non-standard, that will also fail. That's not our fault. And we cannot fix it without image processing.

[probonopd]

If the icon is a valid png file and libpng is installed it should be resized and placed in the right folder properly. If libcairo (which uses libpng) fails to load the file we aren't able to get any information form the file therefore it will have to be just dropped into a well know location.

We need to make this more robust, i.e.

• Bundle the dependencies into the appimaged/AppImageLauncher AppImages
• In case libcairo or libpng are is not available or not working, then appimaged/AppImageLauncher should exit immediately before starting to do anything

[probonopd]

In the same spirit, appimagetool should not proceed if the icons are in non-standard sizes. Then it fails at AppImage creation time which it better than if it sometimes fails for some users at AppImage runtime. AppImage/AppImageKit#975