HaikuDepot only shows vector icons

[humdinger]

This is hrev48724.

Despite having their (bitmap) icons uploaded to the Haiku Depot Server, the HaikuDepot app doesn't display them, but shows the default hpkg icon. E.g. a_book or album.

[richienyhus]

It would look bit ugly to have a whole bunch of large bitmap icons in HaikuDepot.

The real issue is that the Album icon in the HaikuDepot server should be up graded to the new vector icon for it (​http://haikuware.com/directory/view-details/system-files/icons/haikued-bb-icons), while Abook nends an icon created for it (a book with a clock on it?) and uploaded there as well.

[stippi]

I tend to agree with richienyhus. Maybe the functionality to upload PNGs at all should be stripped from the web app. But the problem then is that the web app would need to generate PNGs from the HVIF icon files, and that is quite a programming challenge. All the HVIF code would need to be ported to a POSIX library that can be integrated via JNI at least. Porting to pure Java would be even more work, since the not only the HVIF, but the AGG code is needed, too. So uploading PNGs remains a necessity for the web-app, but it should probably be viewed as such.

[humdinger]

I'm not sure about that. In the regular "list-mode" in HaikuDepot, 16x16 pixel icons are used, so the 16.PNG would fit. Tracker upscales 32px icons to whatever is needed, so HaikuDepot could do the same. Sure, it's not as beautiful, but not too bad most of the time. How big are the other icons in HaikuDepot? (BTW, IMO the icons in the "featured" lists are too big...)

Maybe bitmap icons could stick to 32x32 where big icons are needed?

[waddlesplash]

I tend to agree with richienyhus. Maybe the functionality to upload PNGs at all should be stripped from the web app.

It would look bit ugly to have a whole bunch of large bitmap icons in HaikuDepot.

Some applications have trademarked logos which we can't modify, and so we should upload the original PNGs rather than try to create a HVIF (Firefox, for example, were we to ever get a port). So we need this functionality, even if we don't use it for Haiku/BeOS apps.

[pulkomandy]

There is an SVG version of the Firefox icon. I would either convert that to HVIF or allow HaikuDepot to use SVG, instead of having bitmap icons.

[waddlesplash]

True, but IIRC the last time I opened it in Inkscape, it took a whole 15s to render it (without hardware acceleration). I haven't tried converting it to HVIF but I'm not sure if it would render any faster...

[diver]

Without PNG support most packages will never have icons as it's unrealistic to draw all of them in HVIF unless there would be a png to hvif converter.

[stippi]

Following your line of thought, it would be unrealistic that all software would have icons in Haiku, unless Haiku would support PNG icons alongside HVIF. I agree that Haiku should support icons in some regular image formats, probably at least PNG and JPEG. But that support should not be realized in HaikuDepot, but in the system itself.

To explain: HaikuDepot just receives an opaque buffer of icon data, it does not have any special support for HVIF. It passes the icon data buffer to the libicon API living in libbe, and lets it render into a BBitmap. This mechanism would not require any changes in HaikuDepot, should support be added to libicon to recognize PNG or JPEG buffers or some new format which could store multiple resolutions of PNGs.

[humdinger]

(In #13034) I agree with you.

[apl-haiku]

This should be resolved in hrev50905