tags:

views:

53

answers:

3

Could someone please explain, why many programs have their icons' paths this way: /usr/share/program/icons/hicolor/16x16/...

What I don't understand is why hicolor and why 16x16, 32x32 etc.

Are there any functions (e.g. in GTK) that automatically get the proper icon from such kind of paths?

Thank you!

+2  A: 

The term "hicolor" is the name of the standard icon set which is the fallback for all other icon sets, which means, that if an application's icon is not found in the current icon set (e.g. /usr/share/icons/oxygen) the hicolor directory is searched next.

16x16, 32x32 is imply the size of the images, stored in that directory, as the icons are stored as simple PNG files, which contain exactly one image (unlike, e.g. .icns on mac).

cypheon
+5  A: 

Those icon paths are standardized by the Icon Theme Specification. The reasoning is that all applications can install their default icons into the hicolor theme (which is the default theme, meaning that if an icon is missing from another theme, the version from hicolor will be used.)

Also, a program can request an icon size that is different from the ones provided, say 37x37, and the system will select the most appropriate available size (like 32x32) and scale it to the requested size.

If someone wants to override the application's icon, for example to make a high-contrast black-and-white version for users with poor eyesight, then all they have to do is to make an icon with the same name and put it in the high-contrast black-and-white theme, and it will override the hicolor icon.

The functions you ask about also exist. In GTK there are functions that take a const gchar *icon_name parameter, such as gtk_image_new_from_icon_name(). These will load the icon with the name you supply from the current theme, and if it doesn't exist in the current theme, then from the hicolor theme.

ptomato
A: 

If the question is not "Why 'hicolor'?" as others have answered but "Why use the filesystem as a tree-like database?" the answer is that most unix filesystems (all the old ones) bog down when walking paths where there are more than ~1000 entries in a directory.

Because directories in those filesystems have to be searched linearly.

Some more modern filesystems support O(log N) searches and can deal with higher counts efficiently.

dmckee