> Am 27.02.2021 um 00:04 schrieb Bertrand Dekoninck > <[email protected]>: > Le 26/02/2021 à 23:18, Fred Kiefer a écrit : >> Just to understand the issue a bit better. Are you using libicns to read the >> icns file or is the fallback to the GNUstep implementation used? The later >> implementation is rather limited and won’t be able to handle your added >> formats. >> >> And why didn’t you add a 48x48 version? > > To be clearer : I add for each app a resource folder in > Sombre.theme/Resources. Here, I add Sombre.theme/Resources/org.gap.InnerSpace. > > And I place the custom icon inside. It must be named as is named the appicon > in InnerSpace plist file : InnerSpace_Icon.icns. > > I tried to replace it with a 48x48 InnerSpace_Icon.tiff but it didn't work. > Should it work ? If so, I must have missed something and should retry. I > remember to have replaced tiff files with png files in rik.theme long ago.
Using a different type should be possible but only one file (with the same base name) at the time would be allowed. But I was asking why you didn’t use 48x48 inside of the icns file. > So to answer your question, I don't think I use libicns, unless GWorkspace > uses it to read icns files. But I don't see this library in its dependancies. The libicns would be used directly by GWorkspace. It gets used by GNUstep gun, if present and if not we fall back to the local implementation in GNUstep gui. In the meantime I checked the libicns source code and they do support more formats than our code, but not the @2 and also not the PNG subtype you are using. > I would like to be able to reproduce the same sizes as Greg in my icns file, > but I don't know how. If I don't generate the missing @2x files with my > conversion script, iconutil complains about them and fail on osX ElCapitan. I > tried my conversion script on osX Leopard, but it misses the iconutil tool. Having more formats in the file won’t do any harm. All the supported formats will get ignored.
