Page MenuHome

Support user icon sheets in PNG format
Needs RevisionPublic

Authored by gsr b3d (gsrb3d) on Apr 15 2019, 3:45 AM.
Tags
None
Tokens
"Love" token, awarded by StroBlend."Love" token, awarded by lamoot."Like" token, awarded by riidom."Love" token, awarded by jendrzych."Love" token, awarded by eobet."Burninate" token, awarded by DotBow."Party Time" token, awarded by Modanung."Love" token, awarded by ThinkingPolygons."Like" token, awarded by marcog.

Details

Summary

Users will be able to override icons by saving files to
DATAFILES/icons/ eg ~/.config/blender/2.80/datafiles/icons/
which probably must be created first.

Files use fixed names blender_icons.16.png and blender_icons.32.png
and conform to current dimensions as compiled in the binary. No
need of having both files, fallbacks to compiled in version(s).

Wrong size or unknow file type will be reported, so put tiny PNGs
and you will see the expected sizes easily.

Diff Detail

Repository
rB Blender
Branch
user-png-icon-loading (branched from master)
Build Status
Buildable 3327
Build 3327: arc lint + arc unit

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.Apr 15 2019, 2:44 PM

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.

source/blender/editors/interface/interface_icons.c
709

The PNG file generated by blender_icons_update.py is called blender_icons16.png. It's easiest to keep that without adding the extra dot.

718–719

Use CLOG_WARN for these kinds of prints.

This revision now requires changes to proceed.Apr 15 2019, 2:44 PM

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?

Oleg (DotBow) added a comment.EditedApr 19 2019, 11:49 AM

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.

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.

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?