New icons for Blender 2.8

[Notformortaleyes]

I vote for the safe

[brecht]

@BTolputt

According to Brecht, it is not something they are inclined to look into at all. They might accept a patch by someone else… but it’s not guaranteed and I know from looking at the code they’d be mighty hesitant to have developers they haven’t worked with before play in that area.

I clearly said I would be happy to accept a patch.

Internal icons are loaded once, at a known size, from known binary data compiled into the executable and then never cleaned up. Changes to this code will require not only adding memory management code to internal icons that doesn’t currently exist, but the rest of the UI code not having taken advantage of that “once and done” memory allocation (such as keeping pointer values locally it shouldn’t have).

Memory management is a non-issue, it would just be a handful lines of the code.

The main work is providing tools to generate icons in this format and writing file loader code for it.

[BTolputt]

@brecht

I clearly said I would be happy to accept a patch.

If you’re clarifying that “happy to accept” means a working patch will be added vs “happy to accept” meaning - we’ll check if Ton wants the feature after you’ve done the work and, if not, we’ll just jerk you around for a month before admitting it’s not being merged - I’m very happy.

I’ve been subject to the latter and, quite frankly, it soured me on doing anything in the UI code, that Ton hasn’t expressly stated he’s going to allow.

@brecht

Memory management is a non-issue, it would just be a handful lines of the code.

I was actually more worried about other parts of Blender having been able to take advantage of the “one & done” nature of that memory allocation. Assuming that BKE_icon_delete works as I understand, it’s actually pretty easy to write the memory management code assuming no-one has taken advantage of the fact that internal icons, once allocated, stick around until app death. That’s the code crawling aspect I think no-one really wants to undertake. I know I couldn’t without a HUGE investment in time. If someone can stipulate that’s not the case - I can make a patch on the weekend.

@brecht

The main work is providing tools to generate icons in this format and writing file loader code for it.

Unless I am missing something, there is already code that generates icons in the binary format - it just provides that as a C source code file rather than writing to an “icons.dat” or similar binary file. Is it using something esoteric I am missing here?

[brecht]

@BTolputt

If you’re clarifying that “happy to accept” means a working patch will be added vs “happy to accept” meaning - we’ll check if Ton wants the feature after you’ve done the work and, if not, we’ll just jerk you around for a month before admitting it’s not being merged - I’m very happy.

Ton is not involved in code review. I am the person who would be reviewing the patch and I’m saying I would commit it.

I was actually more worried about other parts of Blender having been able to take advantage of the “one & done” nature of that memory allocation. Assuming that BKE_icon_delete works as I understand, it’s actually pretty easy to write the memory management code assuming no-one has taken advantage of the fact that internal icons, once allocated, stick around until app death. That’s the code crawling aspect I think no-one really wants to undertake. I know I couldn’t without a HUGE investment in time. If someone can stipulate that’s not the case - I can make a patch on the weekend.

The code is not in blenkernel, it is in init_internal_icons in interface_icons.c. It is only an OpenGL texture that needs to be reloaded, the icons are defined at offsets within that texture.

Unless I am missing something, there is already code that generates icons in the binary format - it just provides that as a C source code file rather than writing to an “icons.dat” or similar binary file. Is it using something esoteric I am missing here?

It actually seems even simpler, it is still loading a png file generated from the dat file, so probably custom icons don’t need to go through the dat file. There is some remaining code for loading custom icons, but it was never updated to handle the separate 16x16 and 32x32 icon files. There will likely also need to be an option to indicate if the icon set is monochrome or not, to disable the icon color coding.

[BTolputt]

@brecht

Ton is not involved in code review. I am the person who would be reviewing the patch and I’m saying I would commit it.

Understood. Ton is not in the loop on this one. I’ll put together a patch on the weekend.

@brecht

The code is not in blenkernel, it is in init_internal_icons in interface_icons.c . It is only an OpenGL texture that needs to be reloaded, the icons are defined at offsets within that texture.

I know that, but that code uses the BKE_icon_get / BKE_icon_getset functions that are in blenkernel, and it is possible (though unwise) for a coder to store the Icon pointer returned from those functions.

If you’re saying that this pointer is never stored elsewhere, or would be considered someone else’s bug if they did store it, then I can see pretty much everything I need to do for loading custom icons and can get started this weekend.

@brecht

It actually seems even simpler, it is still loading a png file generated from the dat file, so probably custom icons don’t need to go through the dat file. There is some remaining code for loading custom icons, but it was never updated to handle the separate 16x16 and 32x32 icon files.

I was looking at the brushes/matcap code above and thought that would be a reasonable basis for loading custom code as long as I can thread-safe delete and reload new icons without Blender trying to use memory between starting/ending the theme reload.

@brecht

There will likely also need to be an option to indicate if the icon set is monochrome or not, to disable the icon color coding.

Assuming there is but one icon set per theme - this would be a theme variable correct? The image is loaded “as is” but gets multiplied as desired at draw-time, not load time.

Which brings me to a crucial point on my time - how far does my patch need to go to be accepted? I have looked at the code needed for loading a custom iconset for a theme load (easy enough) but I have not looked at all the drawing code for that icon. Where are the colours to these monochrome icons applied so I can get the scope of that change?

[apoclypse]

I wonder if these icons are being designed with accessibility in mind? I have really bad eyesight in general and I find the new icons borderline unreadable. Too much small detail that is just a blur to my aging eyes and no color to pick out what I’m looking at. I literally have to press my nose to my screen to tell what anything is.

You can’t get used to not being able to tell what you are looking at and that’s at 1.50 UI scaling.

Take something like Affinity or even PS, which I think is the impetus for the monochromatic icons. Even at a glance the icons have nice silhouettes and are easily identifiable. I’m not getting the same thing from these icons. It’s really hard for me to identify what I’m looking unless I actually get close to the screen. There’s too much visual noise to some of the icons that are just a big blur to my eyes.

Some icons are so abstract that its hard to tell what they represent so I have to lean into my screen to see what they are supposed to be. That’s probably going to get extremely frustrating to me rather quickly.

[ThinkingPolygons]

I feel you. I’m relying exclusively on tooltips now.

[brecht]

@BTolputt

If you’re saying that this pointer is never stored elsewhere, or would be considered someone else’s bug if they did store it, then I can see pretty much everything I need to do for loading custom icons and can get started this weekend.

There is no need to free any Icon when loading UI icons, only an OpenGL texture containing all the icons needs to be updated.

I was looking at the brushes/matcap code above and thought that would be a reasonable basis for loading custom code as long as I can thread-safe delete and reload new icons without Blender trying to use memory between starting/ending the theme reload.

Just use the code in init_internal_icons, no need to involve the brush/matcap code.

Assuming there is but one icon set per theme - this would be a theme variable correct? The image is loaded “as is” but gets multiplied as desired at draw-time, not load time.

Yes.

Which brings me to a crucial point on my time - how far does my patch need to go to be accepted?

It needs to work and not introduce any known bugs.

I have looked at the code needed for loading a custom iconset for a theme load (easy enough) but I have not looked at all the drawing code for that icon. Where are the colours to these monochrome icons applied so I can get the scope of that change?

Search for ICON_TYPE_MONO_TEXTURE in interface_icons.c.

[rawalanche]

Oh god please no. Blender’s theme editor actually suffers from such a granularity that making themes is a matter of days, instead of minutes. This is exactly the kind of complexity which should be removed from the theme editor, not added.

HSV for all the icons is fine, but per icon color is a ridiculous concept given how many are there.

Here is what a proper theme editor should look like in any modern piece of software:

People generally only care about two things
1, Brightness of their user interface - most prefer dark, while few prefer bright. Some prefer very dark, others like lighter gray.
2, Accent color, some people like or dislike certain colors.

That’s pretty much it, anything else, like relative tones of the UI elements and so on should be done automatically to maintain some design language.

If you take look at pretty much any Blender theme out there that looks at least somewhat reasonable, you will see it’s pretty much always just a combination of certain UI brightness with one specific accent color. That’s it, so it should be as simple to set up as that. It should take seconds, not days. Every blender theme I’ve done thus far took me about 8-10 hours, because of what a granular, fractured mess it is.

EDIT: More examples here: https://forums.unrealengine.com/unreal-engine/feedback-for-epic/109801-unreal-engine-4-deserves-clean-ui
It shows how many nice UI variations can be produced by just two settings (leaving rest automatized).

[Daniel_Paul]

This makes so much sense. This unreal interface looks really nice btw.

[Mr_Flamey]

Bit off topic, but I am in total agreement with this. The two things you mentioned are definitely all I want to change about Blender’s themes, but there are several hundred settings for different editors and things. I’m not saying those shouldn’t exist for people who like to get a bit crazy, but for the rest of us, simply tweaking panel brightness, contrast and an accent is enough. The only other settings I’ve changed are noodle curliness and transparency of UI over viewport.

It would be nice if the icon colours could be changed with the text or accent colour to match the theme.

[ThinkingPolygons]

Nah, it’s too limiting.
Blender’s theming power is great, it just needs to be more organized, and some settings needs to be decoupled for more flexibility, and that’s all.

[Charlie]

I think the accent idea is great but probably best suited to a plug in that groups settings together for brightness, accent (hue) and contrast. The plugin would expose eight or so swatches which would be used to set all the other colours automatically.

[joahua]

Concerning basic settings vs. granularity…

Vray (for 3ds max at least) have a very nifty concept called UI modes:

Were the user can flip through 3 levels of ‘setting granularity’ - default, advanced & expert.

Down the road (when Blender 2.8 UI gets more refined) I personally think it could be interesting to implement something like this selected places in Blenders UI.
Maybe just a icon that flips between basic and advanced ‘setting granularity’.

Theme settings could be such a place.

As basic theme settings, I agree with you that the Unreal solution seems like a well-thought-out implementation (though I have not used the program).

[BTolputt]

@brecht

There is no need to free any Icon when loading UI icons, only an OpenGL texture containing all the icons needs to be updated.

I think we’re talking across each other at this point, but no hassles. I’ll implement what I think is needed here and I’m sure you’ll let me know if I misunderstood a requirement.

@brecht

It needs to work and not introduce any known bugs.

Another instance where I think we’re not communicating effectively. I’m looking for the level of functionality needed for “It needs to work”. Am I needing to add a filename variables (pointing to the 16x & 32x PNG files) to the theme structures, add the Python UI for setting these variables, and so on… or would a function allowing me to pass in two binary blocks (& their size) representing these file suffice allowing someone more familiar with the theme structures, RNA setup, and Python UI to connect to it?

I’m aware the functionality provided needs to be bug free (I am a software engineer for a living); but that’s not telling me how far that functionality needs to extend. Am I writing internal extensions or do I need to touch outside the interface_icons.* files?

[Evandro_Costa]

I like it, but like @ThinkingPolygons, I also like the customization of the theme preferences.
And I’m always in favor of merging two ideas when both appear to please two different types of people.

I agree that in my post the customization is too much (even though it may please a fraction of people). On DevTalk, @William proposed to have Icon Categories. Like on that Unreal screenshot, you can see that Modes have all beige pastel colors, Toolbar have all lightblue colors, etc. In Blender you’d then have control over that Beige color, and that Lightblue color, instead of individual icon color, which I think is good enough in terms of customization.

Therefore I’d have no problem with having what you suggest (global coloring) on top of (as a first “pass”) a more detailed (icon category) panel. If you don’t want to bother with individual stuff, you’d change the global “Accent” coloring and have an automatic system do it for you…
ex: modifier_group_icon_color = base_Accent_color_3*[0.5H, 0.4S, 0.43V]
but if you wanted you could go to modifier_group_icon_color directly and move the sliders as you wish.

Edit: yeah this is basically what @joahua just mentioned above.

[BTolputt]

@rawalanche

Oh god please no. Blender’s theme editor actually suffers from such a granularity that making themes is a matter of days, instead of minutes. This is exactly the kind of complexity which should be removed from the theme editor, not added.

HSV for all the icons is fine, but per icon color is a ridiculous concept given how many are there.

I sort of agree with you here - per icon is WAY too granular. Problem is, that a global HSV isn’t going to fix the problem that’s been presented. The issue is that the icons are hard(er) to differentiate when all the same colour & value; which is why colouring them was raised in the first place. A global HSV changes that colour/value from white to some other global, nondifferentiable colour keeping the problem.

There are two solutions to this as I see it. One I am working on (letting theme designers colour icons as they see fit) or having the icons grouped into categories and the theme setting the HSV attributes for each category. Personally, I prefer the idea of theme designers getting access to the icons themselves and doing what they see fit in graphics apps across the iconset; but I could see the point of BF devs going the category option if desired.

[rawalanche]

@ThinkingPolygons

Nah, it’s too limiting.
Blender’s theming power is great, it just needs to be more organized, and some settings needs to be decoupled for more flexibility, and that’s all.

Decoupling would mean even more settings. Even now, not many people have patience to actually make their own theme given how much time it already takes. This would make it even worse.

@joahua

Concerning basic settings vs. granularity…

Vray (for 3ds max at least) have a very nifty concept called [UI modes]

Were the user can flip through 3 levels of ‘setting granularity’ - default, advanced & expert.

And most Vray users actually hate it and wish it never existed, because quite a few settings which many people have to touch on day to day basis were actually hidden in advanced or even expert modes, so everyone actually ended up with everything turned on all the time. This solution would just give developer excuse to not maintain and update the theme system properly. The theme system has to be so good that the user won’t have a need to ever get into any advanced mode in the first place. If they do, then it’s not a good system.

Just take a look at those screenshots in my post above. If Blender UI theming worked and looked like that, the I doubt anyone would miss current theme setup.

@Evandro_Costa

I agree that in my post the customization is too much (even though it may please a fraction of people). On DevTalk, @William proposed to have Icon Categories . Like on that Unreal screenshot, you can see that Modes have all beige pastel colors, Toolbar have all lightblue colors, etc. In Blender you’d then have control over that Beige color, and that Lightblue color, instead of individual icon color, which I think is good enough in terms of customization.

Therefore I’d have no problem with having what you suggest (global coloring) on top of (as a first “pass”) a more detailed (icon category) panel. If you don’t want to bother with individual stuff, you’d change the global “Accent” coloring and have an automatic system do it for you…
ex: modifier_group_icon_color = base_Accent_color_3*[0.5H, 0.4S, 0.43V]
but if you wanted you could go to modifier_group_icon_color directly and move the sliders as you wish.

I agree that primary and secondary icon colors could be simple enough.

[rawalanche]

I was talking about Blender’s theme system in general, which kinda grinds my gears for a while already. It was a reaction to someone above suggesting adding even more options to a theme setup which is so overloaded with options already that it’s borderline impossible to set up a theme in any reasonable amount of time.

Regarding colorizing just icons, I’ve actually made a proposal about it in this very thread few posts above:

New icons for Blender 2.8

I did one more experiment using the Microsoft/Newer Autodesk styles, where parts of the icons are tinted by the main accent color of a given theme: [image] I think it helps with the issue of the icons blending with the text, making them pop a bit more. But at the same time, it’d require someone to go through and create another sheet of masks for tinted icon elements.

Basically, I’d like icons to just have one base color and one accent color matching overall theme accent color, that’s it

[brecht]

@BTolputt

Another instance where I think we’re not communicating effectively. I’m looking for the level of functionality needed for “It needs to work”. Am I needing to add a filename variables (pointing to the 16x & 32x PNG files) to the theme structures, add the Python UI for setting these variables, and so on… or would a function allowing me to pass in two binary blocks (& their size) representing these file suffice allowing someone more familiar with the theme structures, RNA setup, and Python UI to connect to it?

I expect it to include a UI and everything else needed to get it to a working state. Normally for code contributions the intent is to commit the patch as written by the contributor (after they made modifications from code review). Not to serve as a starting point for other developers.

In this case the code that takes the binary PNG data is already there as far as I can tell, hooking it up to the rest of Blender is where most of the work is.