Named vector icons and purpose of B_GET_ICON_NAME ioctl opcode?

Development OS
1

I think I miss when this was introduced, but I’ve discovered that in multiple place of Haiku code, near some code returning a vector icon data (cf B_GET_VECTOR_ICON ioctl implemented in multiple drivers for instance), there is also this other B_GET_ICON_NAME ioctl which returns a “icon name” string instead.

Only in the storage kit I could find some userland code that actually call it to try to load a vector icon data from an external resource, by its name, by looking for a file under the followed root directories:

/boot/home/config/non-packaged/data/icons/<icon name>
/boot/home/config/data/icons/<icon name>
/boot/system/non-packaged/data/icons/<icon name>
/boot/system/data/icons/<icon name>

Except by default there is nothing there. And it then fallback to use B_GET_VECTOR_ICON to retrieve the HVIF icon raw data.

But there are many icons files under /boot/system/data/icons/haiku/*, but all are in SVG format, not HVIF.

I guess this icon name concept is to allow end user to customized its set of icons (and slowly prepare the whole Haiku to support this possibility) ?
Or to move all currently hardcoded HVIF raw bytes out of source code files, but something get lost since?

I’m wondering because recently I added support in midi_server for MIDI devices to expose their own custom vector icons, and I was wondering if I should also support, then, this concept of icon name too.

2

These are not part of Haiku, they are installed as a dependency for Qt or GTK apps, which don’t know how to use HVIF icons and need them pre-converted to a different format.

I think it was never really completed. The idea would be to have some “standard” icons in the OS so that each driver doesn’t need to provide its own one.

Driver specific icons make sense in some cases (for example, specific USB devices that have distinctive looks), but doesn’t make much sense in other cases. The storage kit implements it because it makes sense for the driver to just say “this is a CD drive, use a CD icon” or “this is a floppy disk drive, use a floppy icon” and then the icon can be stored once in an icon store, and not copied into every driver. And only in cases where a drive is specific and recognizable (let’s say, a ZIP-100 SCSI drive with its blue case), the driver could provide a dedicated icon.

However, storing the icons as files in a directory will likely waste more space than it saves. So maybe this should be reconsidered to have them stored in some packed format (attributes? resources? something else?)