A bit busy until next month.

As for names, blender_icons.color32.png make sense with the added complexity, that way all them are "common thing dot tech details dot extension".

To advance things and avoid spurious work, what order of precedence? Color over Mono? Mono over Color? What happens if there is a mix of style avaliable?

Any other thing?

Couldn't it automatically detect mono or color PNG and in the latter case disable the colorization?

In D4683#106672, @Brecht Van Lommel (brecht) wrote:

One problem is that the current icon loading code assumes monochrome icons. For a colored icon set this means the icons will be tinted with with text and theme colors, which is not great.

The easiest way to distinguish between such icons would be based on the filename. For example if it's called blender_icons_mono_32.png it could do the same as it does now, and for blender_icons_color_32.png it could set all of them with type ICON_TYPE_COLOR_TEXTURE.

Isn't the easiest way to distinguish between such icons is to add actual property to preferences i.e. "Use Colored Icons" or enum value Colored/Monochrome?

Read the topic again - it seems we will not have actual interface for loading icons.
How then we will prevent loosing original icons file?

A preference adds more manual work for the user for no reason, the icon set itself defines if it's monochrome or not.

Custom icon sets would be installed to the user config directory just like add-ons, not overwriting any default Blender data.

In D4683#107273, @gsr b3d (gsrb3d) wrote:

As for names, blender_icons.color32.png make sense with the added complexity, that way all them are "common thing dot tech details dot extension".

We don't use that kind of naming for any other Blender configuration files, mostly just separate with underscores. So I'd prefer to stick to that for consistency.

To advance things and avoid spurious work, what order of precedence? Color over Mono? Mono over Color? What happens if there is a mix of style avaliable?

Color over mono I guess, since it's the main reason users would install custom icons. Mix of styles in the same icon sheet would just not be supported I think.

Back... with hiccups. Got conflict in the clang-format dance, started updating with the basics, then everything trashed in bigger conflcit. So restarting once I figure the new state of the code.

In D4683#107313, @Brecht Van Lommel (brecht) wrote:

In D4683#107273, @gsr b3d (gsrb3d) wrote:

As for names, blender_icons.color32.png make sense with the added complexity, that way all them are "common thing dot tech details dot extension".

We don't use that kind of naming for any other Blender configuration files, mostly just separate with underscores. So I'd prefer to stick to that for consistency.

Idea came after seeing things like brush.gpencil_draw.draw.dat and icon32_action.dat, IE namings vary. So went with glob-friendly (*.color*.png, *.*16.png, etc).

To advance things and avoid spurious work, what order of precedence? Color over Mono? Mono over Color? What happens if there is a mix of style avaliable?

Color over mono I guess, since it's the main reason users would install custom icons. Mix of styles in the same icon sheet would just not be supported I think.

I was talking about having mismatched files, color in 16 and mono in 32, eg.It can go from only one user file to four being valid. From botched (de)install, or invalid size, for example.
Probably go with color if at least one is, and warn if not all them are.

It will be nice to be able to use different icon sets for different themes.
This can be a theme preference; or use a subfolder or file prefix with the theme name.

"Load Factory Settings" should reset icons to default ones,
to be able to take screenshots, for example for bug reports or tutorials, without removing custom icon files.

It is more correct to use file names with "@2x" since it is not 32px icons, it is 16@2x.

@gsr b3d (gsrb3d) Can something like this be also made for the icons in the toolbar?