Blender 2.8: Icons #53840

Closed
opened 2018-01-19 19:29:15 +01:00 by Pablo Vazquez · 90 comments
Member

Blender 2.8 has many new features that need icons, and in 2.7 already some icons were missing or reused.

This is an open call to anyone interested in contributing to the design of these icons. The list of needed icons is this. The ones marked in bold are the most important ones, others are lower priority but still great to have.

Properties Editor

  • Fake User
  • Delete and Unlink distinction (both are X currently)
  • Tool Settings
  • Preset
  • Icons for next to buttons: None, Animated, Keyframed, Driven, Linked, Overriden, Node Linked (see #54951)

3D viewport

  • Overlay
  • Transform Orientation (Global and View)

Outliner

  • Hide, Viewport Enable and Render Enable distinction
  • Orphan Data mode
  • (Static) Override (see #53500)
  • Complete Match (string search)
  • Case Sensitive (string search)

Node Editor

  • Snapping modes (Node X, Node Y, Node X / Y)

Assert Manager

  • Asset Manager in editors menu

Text Editor

  • Find Next
  • Replace

File Editor

  • 3D/Scene File (Alembic, Collada, ..)
  • Volume File

Future Features

  • Volume Object
  • Hair Object
  • Particle Object

The goal is to extend the current icon set. We are not looking for a re-design in this task, please follow the current icon style as close as possible.

Resources and Reference:

  • Icon Guidelines: #38757
  • #38246 - These icons by @PawelLyczkowski-1 follow very well the current icons style
  • Current blender_icons.svg file as reference:
    blender_icons.svg

Note: This task is a follow up on the now 4-year old #38093

Blender 2.8 has many new features that need icons, and in 2.7 already some icons were missing or reused. This is an open call to anyone interested in contributing to the design of these icons. The list of needed icons is this. The ones marked in bold are the most important ones, others are lower priority but still great to have. ### Properties Editor * Fake User * Delete and Unlink distinction (both are X currently) * **Tool Settings** * Preset * Icons for next to buttons: None, **Animated, Keyframed, Driven, Linked, Overriden**, Node Linked (see #54951) ### 3D viewport * **Overlay** * Transform Orientation (Global and View) ### Outliner * Hide, **Viewport Enable and Render Enable** distinction * Orphan Data mode * **(Static) Override** (see #53500) * Complete Match (string search) * Case Sensitive (string search) ### Node Editor * Snapping modes (Node X, Node Y, Node X / Y) ### Assert Manager * **Asset Manager** in editors menu ### Text Editor * Find Next * Replace ## File Editor * 3D/Scene File (Alembic, Collada, ..) * Volume File ### Future Features * Volume Object * Hair Object * Particle Object The goal is to extend the current icon set. We are not looking for a re-design in this task, please follow the current icon style as close as possible. Resources and Reference: * Icon Guidelines: #38757 * #38246 - These icons by @PawelLyczkowski-1 follow very well the current icons style * Current **blender_icons.svg** file as reference: ![blender_icons.svg](https://archive.blender.org/developer/F1955640/blender_icons.svg) ---- Note: This task is a follow up on the now 4-year old #38093
Author
Member
Added subscribers: @PawelLyczkowski-1, @pablovazquez, @dfelinto

Added subscriber: @antoniov

Added subscriber: @antoniov

@venomgfx As we have already added some icons for GP, it would be good idea to review what slots were used to avoid merge conflicts in the future.

Actually, GP branch have used the following icon slots: T-13, U-14, Y-11

@venomgfx As we have already added some icons for GP, it would be good idea to review what slots were used to avoid merge conflicts in the future. Actually, GP branch have used the following icon slots: T-13, U-14, Y-11

Added subscriber: @PierreSchiller

Added subscriber: @PierreSchiller

Great. I´m in for it. Where´s the "big" list? :D Where are we submit the file? Should we work directly on blender_icons.svg?

Great. I´m in for it. Where´s the "big" list? :D Where are we submit the file? Should we work directly on blender_icons.svg?

I'll try to tackle the Collections icons here: https://developer.blender.org/T53844 Other designers, please go ahead and pick up the other ones.

@PierreSchiller You can post to this task I guess. Use blender_icons.svg as a base, after your icons are accepted they can be added back to blender_icons.svg.

I'll try to tackle the Collections icons here: https://developer.blender.org/T53844 Other designers, please go ahead and pick up the other ones. @PierreSchiller You can post to this task I guess. Use blender_icons.svg as a base, after your icons are accepted they can be added back to blender_icons.svg.

Does anyone know if there are problems when merge .svg files (blender_icons.svg)?

I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

Does anyone know if there are problems when merge .svg files (blender_icons.svg)? I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

In #53840#480568, @antoniov wrote:
Does anyone know if there are problems when merge .svg files (blender_icons.svg)?

I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

Sometimes yes there are merge conflicts. You can merge blender_icons.svg from greasepencil into 2.8 before greasepencil itself is ready. I did the same for multi-view for the exactly same reasons.

> In #53840#480568, @antoniov wrote: > Does anyone know if there are problems when merge .svg files (blender_icons.svg)? > > I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future. Sometimes yes there are merge conflicts. You can merge blender_icons.svg from greasepencil into 2.8 before greasepencil itself is ready. I did the same for multi-view for the exactly same reasons.

Added subscriber: @RayMairlot

Added subscriber: @RayMairlot

Added subscriber: @JonathanLampel-4

Added subscriber: @JonathanLampel-4
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

In #53840#480568, @antoniov wrote:
Does anyone know if there are problems when merge .svg files (blender_icons.svg)?

I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

When adding icons the blender_icons.svg, it tends to get lots of unneeded changes. Only a rather small & isolated subset of those are actually needed, e.g. see this commit which adds two icons. One has to manually remove most unwanted changes I'm afraid. This should however get rid of most merge conflicts.


We'll also need an icon for workspaces for 2.8.

> In #53840#480568, @antoniov wrote: > Does anyone know if there are problems when merge .svg files (blender_icons.svg)? > > I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future. When adding icons the blender_icons.svg, it tends to get *lots* of unneeded changes. Only a rather small & isolated subset of those are actually needed, e.g. see [this commit](https://developer.blender.org/rB0dd6e5bfee3dee0ced7#change-9wjdv.Fnua95) which adds two icons. One has to manually remove most unwanted changes I'm afraid. This should however get rid of most merge conflicts. --- We'll also need an icon for workspaces for 2.8.

Added subscriber: @MartinSanchez-3

Added subscriber: @MartinSanchez-3

@JulianEisel Add new icons is not the problem. The problem is that it's very easy to overwrite a new icon created in a different branch, because designer usually use the first free slot. The idea of merge is to "fill" these slots and avoid overwritten.

@JulianEisel Add new icons is not the problem. The problem is that it's very easy to overwrite a new icon created in a different branch, because designer usually use the first free slot. The idea of merge is to "fill" these slots and avoid overwritten.

Removed subscriber: @RayMairlot

Removed subscriber: @RayMairlot

Added subscriber: @JosberthArellano

Added subscriber: @JosberthArellano

Added subscriber: @kednar

Added subscriber: @kednar

First attempt.

Concepts opc 1:
Object container box

Concepts opc 2:
Grouping of leaves with objects

FIRST.png

First attempt. Concepts opc 1: Object container box Concepts opc 2: Grouping of leaves with objects ![FIRST.png](https://archive.blender.org/developer/F1982122/FIRST.png)

I'm thinking new ideas for link, unlink, add and remove. It is not convenient that they are the same icons as the collections. It's confusing.

I'm thinking new ideas for link, unlink, add and remove. It is not convenient that they are the same icons as the collections. It's confusing.

Added subscriber: @michaelknubben

Added subscriber: @michaelknubben

Added subscriber: @wevon-2

Added subscriber: @wevon-2

My proposal for the probes
Probes.jpg
Probes.svg

My proposal for the probes ![Probes.jpg](https://archive.blender.org/developer/F2095697/Probes.jpg) ![Probes.svg](https://archive.blender.org/developer/F2095700/Probes.svg)

I have made stickers for the Overrides. They are red as the record icon, I do not know if it is the best option.
Overrrides.jpg
Overrides.svg

I have made stickers for the Overrides. They are red as the record icon, I do not know if it is the best option. ![Overrrides.jpg](https://archive.blender.org/developer/F2102404/Overrrides.jpg) ![Overrides.svg](https://archive.blender.org/developer/F2102409/Overrides.svg)

Added subscriber: @zeauro

Added subscriber: @zeauro

About probes :
Ideally , their icons should be recognizable by their silhouette. They need a yellow variation to distinguish Object and Object Data.

About overrides :
It would be better to take color that will be used in default Theme UI. Red is generally used as a warning about something that is going wrong.
Maybe + and x are too small. If you take a look to File Menu icons. Additionnal green arrows are not discrete at all.
Silhouette of override icon should be recognizable if it is half masked by additionnal indication.

About probes : Ideally , their icons should be recognizable by their silhouette. They need a yellow variation to distinguish Object and Object Data. About overrides : It would be better to take color that will be used in default Theme UI. Red is generally used as a warning about something that is going wrong. Maybe + and x are too small. If you take a look to File Menu icons. Additionnal green arrows are not discrete at all. Silhouette of override icon should be recognizable if it is half masked by additionnal indication.

In #53840#483133, @zeauro wrote:
About probes :
Ideally , their icons should be recognizable by their silhouette. They need a yellow variation to distinguish Object and Object Data.

True. Here a new proposal.
Probes_02.png

About overrides :
It would be better to take color that will be used in default Theme UI. Red is generally used as a warning about something that is going wrong.

The red was to alert that it was overwritten, anyway I have done a test varying the tone and saturation.

Maybe + and x are too small. If you take a look to File Menu icons. Additionnal green arrows are not discrete at all.

I've done the test, but I think the crosses have to contrast their size with the main shape of the icon.

On the other hand I have modified the shape of the fold slightly and I have made a variant to show the dynamism of the overwritten one. There is also a test projecting shadow.
Overrides_02.png

I group everything in a file in case someone wants to play.
Thanks for comment
Overrides i Probes.svg

> In #53840#483133, @zeauro wrote: > About probes : > Ideally , their icons should be recognizable by their silhouette. They need a yellow variation to distinguish Object and Object Data. True. Here a new proposal. ![Probes_02.png](https://archive.blender.org/developer/F2103826/Probes_02.png) > About overrides : > It would be better to take color that will be used in default Theme UI. Red is generally used as a warning about something that is going wrong. The red was to alert that it was overwritten, anyway I have done a test varying the tone and saturation. > Maybe + and x are too small. If you take a look to File Menu icons. Additionnal green arrows are not discrete at all. I've done the test, but I think the crosses have to contrast their size with the main shape of the icon. On the other hand I have modified the shape of the fold slightly and I have made a variant to show the dynamism of the overwritten one. There is also a test projecting shadow. ![Overrides_02.png](https://archive.blender.org/developer/F2103847/Overrides_02.png) I group everything in a file in case someone wants to play. Thanks for comment ![Overrides i Probes.svg](https://archive.blender.org/developer/F2103852/Overrides_i_Probes.svg)

The last of today
Filter.png

Filters

  Children Objects (new filter in the Outliner)
  Object Data (new filter in the Outliner, used to show/hide the datablock of each object)

Filter.svg

The last of today ![Filter.png](https://archive.blender.org/developer/F2107443/Filter.png) Filters ``` Children Objects (new filter in the Outliner) Object Data (new filter in the Outliner, used to show/hide the datablock of each object) ``` ![Filter.svg](https://archive.blender.org/developer/F2107449/Filter.svg)

Taking into account some criticisms I have adjusted the design of the overwritten ones.
I leave you alone until next weekend :)
Overrides_03.png
Overrides_03.svg

Taking into account some criticisms I have adjusted the design of the overwritten ones. I leave you alone until next weekend :) ![Overrides_03.png](https://archive.blender.org/developer/F2115466/Overrides_03.png) ![Overrides_03.svg](https://archive.blender.org/developer/F2115471/Overrides_03.svg)

I could not resist. Here is a completely different proposal for the Overrides.
Overrides_04.png
OverrideNew_01.svg

I could not resist. Here is a completely different proposal for the Overrides. ![Overrides_04.png](https://archive.blender.org/developer/F2139829/Overrides_04.png) ![OverrideNew_01.svg](https://archive.blender.org/developer/F2139835/OverrideNew_01.svg)

Added subscriber: @jenkm

Added subscriber: @jenkm

This comment was removed by @jenkm

*This comment was removed by @jenkm*

Another attempt for static and dynamic overwriting.
Collections.jpg
OverrideNew_01.svg

Another attempt for static and dynamic overwriting. ![Collections.jpg](https://archive.blender.org/developer/F2616233/Collections.jpg) ![OverrideNew_01.svg](https://archive.blender.org/developer/F2616234/OverrideNew_01.svg)

Added subscriber: @AxelMening-4

Added subscriber: @AxelMening-4
Can I propose something like that? https://blenderartists.org/t/blender-2-8-development-thread/674759/2597?u=so3datel https://blenderartists.org/t/blender-2-8-development-thread/674759/2605?u=so3datel
Member

Added subscriber: @jendrzych

Added subscriber: @jendrzych
Member

I just started blender's icon redesign. LINK
Old icons design has a few afflictions:

  • they were designed to be visible on any background - dark or light and thus some crucial space has to be dedicated to double outlines. It consumes a lot of precious space;
  • old icons actually were not true 16x16 pix, but tad smaller - one pixel, two pixels… That’s further space loss;

in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.

Developers input and feedback is highly appreciated, since some of UI concepts are going to change. New design should address listed problems and - by the way, parts of the UI must be retouched (width and height of space dedicated for icons + some border around).

I just started blender's icon redesign. [LINK ](https://blenderartists.org/t/new-icons-for-blender-2-8/1112701/9) Old icons design has a few afflictions: - they were designed to be visible on any background - dark or light and thus some crucial space has to be dedicated to double outlines. It consumes a lot of precious space; - old icons actually were not true 16x16 pix, but tad smaller - one pixel, two pixels… That’s further space loss; # in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items. Developers input and feedback is highly appreciated, since some of UI concepts are going to change. New design should address listed problems and - by the way, parts of the UI must be retouched (width and height of space dedicated for icons + some border around).

Added subscriber: @mendio

Added subscriber: @mendio

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Added subscriber: @brecht

Added subscriber: @brecht

Thanks all for the contributions so far!

I've updated the list of icons that we need. Light probe icons have been committed for a while already, collections use the group icon now since they are merged. Some other features got moved into menus which don't need icons for every operation anymore.

For the static overrides icon, it would be best if we could somehow make it related to the linked icon and redesign both if needed. Basically a datablock can be either local, linked or linked with overrides. In the outliner you right click on a linked object to add overrides to it, and then the document with the arrow in it turning into e.g. a badge would be a bit strange.

Thanks all for the contributions so far! I've updated the list of icons that we need. Light probe icons have been committed for a while already, collections use the group icon now since they are merged. Some other features got moved into menus which don't need icons for every operation anymore. For the static overrides icon, it would be best if we could somehow make it related to the linked icon and redesign both if needed. Basically a datablock can be either local, linked or linked with overrides. In the outliner you right click on a linked object to add overrides to it, and then the document with the arrow in it turning into e.g. a badge would be a bit strange.
Member

As I stated before, I work on new design (flat / monochrome) of icons for 2.8 release. It's independent effort, with no official support, but I stay in touch with William Reinish and Pablo Vazquez, who are interested in my work. Actually a couple of my new icons are in use already - the mice pictograms on the Status Bar. The longer I focus on my projects goals, the more I find: inconsistencies, temporal-once-a-time hacks, design flaws; simple patching up current icon set isn't a solution and - to be honest - is not in pair with all the great work on redesing and cleaning up the GUI. Next week I plan to release the latest mono-icons sheet, that gets more and more complete, but doesn't really fit real needs that 2.8 GUI renders. The release will be folowed by sort of list of changes that should be considered if we want clean an logically organized UI in Blender 2.8.
BTW, my new icons design proposal already contains:

  • Tool Settings,
  • Preset,
  • Complete Match (string search),
  • Case Sensitive (string search),
  • Hair Object,
  • View Transform Orientation,
    and many other new icons, that already use inapropriate symbols...
    Stay tuned on Blenderartists Thread
As I stated before, I work on new design (flat / monochrome) of icons for 2.8 release. It's independent effort, with no official support, but I stay in touch with William Reinish and Pablo Vazquez, who are interested in my work. Actually a couple of my new icons are in use already - the mice pictograms on the Status Bar. The longer I focus on my projects goals, the more I find: inconsistencies, temporal-once-a-time hacks, design flaws; simple patching up current icon set isn't a solution and - to be honest - is not in pair with all the great work on redesing and cleaning up the GUI. Next week I plan to release the latest mono-icons sheet, that gets more and more complete, but doesn't really fit real needs that 2.8 GUI renders. The release will be folowed by sort of list of changes that should be considered if we want clean an logically organized UI in Blender 2.8. BTW, my new icons design proposal already contains: - Tool Settings, - Preset, - Complete Match (string search), - Case Sensitive (string search), - Hair Object, - View Transform Orientation, and many other new icons, that already use inapropriate symbols... Stay tuned on [Blenderartists Thread ](https://blenderartists.org/t/new-icons-for-blender-2-8/1112701)

If you're doing all the icons, that's great. Mainly I wanted to update the task so we don't forgot to fix the missing icons before the beta.

If you're doing all the icons, that's great. Mainly I wanted to update the task so we don't forgot to fix the missing icons before the beta.

@jendrzych, the new icons seem to be a bit bigger. Do you expect the headers and buttons to become bigger as well to accommodate them, or are the icons being designed for the current button size?

@jendrzych, the new icons seem to be a bit bigger. Do you expect the headers and buttons to become bigger as well to accommodate them, or are the icons being designed for the current button size?
Member

@brecht - it's a problem that I reported back in time of 2.5 icons redesign. Current icons are tad smaller than 16x16 pixels - usually 1 or 2 pixels less, while some of pictograms utilize full 16x16 matrix. This causes size diversity across icon sheet. Some of pictograms are smaller, others are fullsize and buttons and other GUI elements are so. Removing black outlines and designing icons bigger leads to better use of available space and clearer symbol rendering. My icons design assumes the need of making headers and buttons at least two pixels bigger - pending massive GUI redesig seems to be perfect time for such tweaks, although I have no idea how big such change can be...

@brecht - it's a problem that I reported back in time of 2.5 icons redesign. Current icons are tad smaller than 16x16 pixels - usually 1 or 2 pixels less, while some of pictograms utilize full 16x16 matrix. This causes size diversity across icon sheet. Some of pictograms are smaller, others are fullsize and buttons and other GUI elements are so. Removing black outlines and designing icons bigger leads to better use of available space and clearer symbol rendering. My icons design assumes the need of making headers and buttons at least two pixels bigger - pending massive GUI redesig seems to be perfect time for such tweaks, although I have no idea how big such change can be...

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

It's not so hard to make all the buttons bigger, you can try this yourself and see how it looks with the icons:

diff --git a/source/blender/windowmanager/intern/wm_window.c b/source/blender/windowmanager/intern/wm_window.c
index 4323185..596af5f 100644
--- a/source/blender/windowmanager/intern/wm_window.c
+++ b/source/blender/windowmanager/intern/wm_window.c
@@ -591,7 +591,7 @@ void WM_window_set_dpi(wmWindow *win)
        U.pixelsize = pixelsize;
        U.dpi = dpi / pixelsize;
        U.virtual_pixel = (pixelsize == 1) ? VIRTUAL_PIXEL_NATIVE : VIRTUAL_PIXEL_DOUBLE;
-       U.widget_unit = (U.pixelsize * U.dpi * 20 + 36) / 72;
+       U.widget_unit = (U.pixelsize * U.dpi * 22 + 36) / 72;
        U.dpi_fac = ((U.pixelsize * (float)U.dpi) / 72.0f);
 
        /* update font drawing */

bigger_buttons.png

If it only needs to be done in some places it will be more difficult.

However I'm not so sure it's a good change to make design wise. Buttons in the Blender UI are already quite big relative to similar software, and if anything I'd be inclined to make them smaller. The new layout in the properties editor also needs more space, adding another 10% to that is not ideal.

@venomgfx and @WilliamReynish are the UI designers though, I would like to hear their opinion on this.

It's not so hard to make all the buttons bigger, you can try this yourself and see how it looks with the icons: ``` diff --git a/source/blender/windowmanager/intern/wm_window.c b/source/blender/windowmanager/intern/wm_window.c index 4323185..596af5f 100644 --- a/source/blender/windowmanager/intern/wm_window.c +++ b/source/blender/windowmanager/intern/wm_window.c @@ -591,7 +591,7 @@ void WM_window_set_dpi(wmWindow *win) U.pixelsize = pixelsize; U.dpi = dpi / pixelsize; U.virtual_pixel = (pixelsize == 1) ? VIRTUAL_PIXEL_NATIVE : VIRTUAL_PIXEL_DOUBLE; - U.widget_unit = (U.pixelsize * U.dpi * 20 + 36) / 72; + U.widget_unit = (U.pixelsize * U.dpi * 22 + 36) / 72; U.dpi_fac = ((U.pixelsize * (float)U.dpi) / 72.0f); /* update font drawing */ ``` ![bigger_buttons.png](https://archive.blender.org/developer/F3846236/bigger_buttons.png) If it only needs to be done in some places it will be more difficult. However I'm not so sure it's a good change to make design wise. Buttons in the Blender UI are already quite big relative to similar software, and if anything I'd be inclined to make them smaller. The new layout in the properties editor also needs more space, adding another 10% to that is not ideal. @venomgfx and @WilliamReynish are the UI designers though, I would like to hear their opinion on this.

I'm good with using all 16*16 points.

@brecht: Don't really understand your image - here it looks like checkboxes are really big?

I'm good with using all 16*16 points. @brecht: Don't really understand your image - here it looks like checkboxes are really big?

The patch makes all the buttons two pixels bigger as suggested by @jendrzych, but keeps the text the same size. I think the screenshot shows roughly what that would look like, though some UI elements could be tweaked like making the checkboxes smaller. Alternatively setting the Display Scale in the user preferences to 1.1 scales everything.

Reference Patch (buttons only) Display Scale 1.1 (everything)
smaller_buttons.png bigger_buttons.png bigger_buttons_and_text.png

I'm just trying to figure out if making the buttons 10% bigger is a good idea and what that would look like. To me it all looks much too big.

The patch makes all the buttons two pixels bigger as suggested by @jendrzych, but keeps the text the same size. I think the screenshot shows roughly what that would look like, though some UI elements could be tweaked like making the checkboxes smaller. Alternatively setting the Display Scale in the user preferences to 1.1 scales everything. |Reference|Patch (buttons only)|Display Scale 1.1 (everything)| | -- | -- | -- | |![smaller_buttons.png](https://archive.blender.org/developer/F3846269/smaller_buttons.png)|![bigger_buttons.png](https://archive.blender.org/developer/F3846271/bigger_buttons.png)|![bigger_buttons_and_text.png](https://archive.blender.org/developer/F3846273/bigger_buttons_and_text.png)| I'm just trying to figure out if making the buttons 10% bigger is a good idea and what that would look like. To me it all looks much too big.

Yes, I see the issue. I have inserted a few of the new icons as replacements:

Before:
Screen Shot 2018-07-02 at 21.20.09.png

After:
Screen Shot 2018-07-02 at 21.19.29.png

Two observations:

  • It's really nice that we can just use simply glyphs without shading and outlines
  • They are a fair bit too big now to fit. There's not enough padding towards the edges.

As a demonstration, I decreased the size of these icons, here:

Screen Shot 2018-07-02 at 21.19.33.png

I don't think we need to increase the size of all our UI widgets. Instead, we could just decrease the size of our icons slightly. With the more simple and flat design, they should work even better than before at the same size.

Yes, I see the issue. I have inserted a few of the new icons as replacements: Before: ![Screen Shot 2018-07-02 at 21.20.09.png](https://archive.blender.org/developer/F3846351/Screen_Shot_2018-07-02_at_21.20.09.png) After: ![Screen Shot 2018-07-02 at 21.19.29.png](https://archive.blender.org/developer/F3846353/Screen_Shot_2018-07-02_at_21.19.29.png) Two observations: - It's really nice that we can just use simply glyphs without shading and outlines - They are a fair bit too big now to fit. There's not enough padding towards the edges. As a demonstration, I decreased the size of these icons, here: ![Screen Shot 2018-07-02 at 21.19.33.png](https://archive.blender.org/developer/F3846356/Screen_Shot_2018-07-02_at_21.19.33.png) I don't think we need to increase the size of all our UI widgets. Instead, we could just decrease the size of our icons slightly. With the more simple and flat design, they should work even better than before at the same size.
Member

I made smaller version of playback icons already - pictograms are tested. Update is coming.
Decreasing size of symbols is possible, but have no sense in most cases. Example provided by William is an extreme - other pictograms are really detailed and I believe they'll will lose from shrinking - mice icons for instance utilize whole 16x16 pix matrix. 2pix penalty in height per header isn't that much, but gives best icon quality.

Personally, I work with hi-res 13in display (not retina) most of time and 16x16 icons are way better tha 14x14 :D

I made smaller version of playback icons already - pictograms are tested. Update is coming. Decreasing size of symbols is possible, but have no sense in most cases. Example provided by William is an extreme - other pictograms are really detailed and I believe they'll will lose from shrinking - mice icons for instance utilize whole 16x16 pix matrix. 2pix penalty in height per header isn't that much, but gives best icon quality. Personally, I work with hi-res 13in display (not retina) most of time and 16x16 icons are way better tha 14x14 :D

The mice icons seem fine as-is. Maybe because they are largely hollow, and also because they are not contained within a button, so padding is less of an issue.

But, a few of the new icons, such as the camera icons, are very detailed at the pixel level - maybe they could be simplified further?

Another thing to consider is the UI widget outlines. If our outlines are less prominent, or same color as buttons, this will give an extra pixel of padding in each direction.

Actually increasing the size of all our UI widgets requires careful consideration, as it means we can display less information in headers and other places. The old icon sizes had that size so they would fit next to text, and be roughly the same height, just like an emoji or other symbols.

For an icon designer like you, it'd be really useful if we had an easier way for you to test your icons in Blender as you make them, otherwise you are fumbling a bit in the dark. Are you able to build Blender yourself?

The mice icons seem fine as-is. Maybe because they are largely hollow, and also because they are not contained within a button, so padding is less of an issue. But, a few of the new icons, such as the camera icons, are very detailed at the pixel level - maybe they could be simplified further? Another thing to consider is the UI widget outlines. If our outlines are less prominent, or same color as buttons, this will give an extra pixel of padding in each direction. Actually increasing the size of all our UI widgets requires careful consideration, as it means we can display less information in headers and other places. The old icon sizes had that size so they would fit next to text, and be roughly the same height, just like an emoji or other symbols. For an icon designer like you, it'd be really useful if we had an easier way for you to test your icons in Blender as you make them, otherwise you are fumbling a bit in the dark. Are you able to build Blender yourself?
Member

Building software is a black magic for me, and - to be honest - I don't have extra time to dig into it.
Leaning over deign of a widget outline is great idea!
Vklidu form blenderartists.org is making great mockups with GUI with no prominent buttons. He has got couple of grat ideas in his thread "monoicons" (status and title bars in black, for example).

Regarding icons size - absolute size of pictogram is not all that has to be considered. It's not less complicated than kerning and font design - some pictograms can be 16x16 pix, but look rather small, just as a camera object does.

Building software is a black magic for me, and - to be honest - I don't have extra time to dig into it. Leaning over deign of a widget outline is great idea! Vklidu form blenderartists.org is making great mockups with GUI with no prominent buttons. He has got couple of grat ideas in his thread "monoicons" (status and title bars in black, for example). Regarding icons size - absolute size of pictogram is not all that has to be considered. It's not less complicated than kerning and font design - some pictograms can be 16x16 pix, but look rather small, just as a camera object does.
Member

SVG with updated icons ready to grab: HERE

SVG with updated icons ready to grab: [HERE ](https://blenderartists.org/t/new-icons-for-blender-2-8/1112701)

Added subscriber: @a.monti

Added subscriber: @a.monti

I've just compiled blender with a decreased size version of your icons (I tried 80% of the originals, it may be too much but I don't really know) @jendrzych and everything looks way better in my opinion.
000612.png
There may be a couple of icons that would need a small adjustment, but overall they seems fine to me.

I have a concern about the design though, I like flat and shadeless stuff, but that comes with quite a big problem: having the icons solid white while having no outline makes it impossible to use a bright theme or a bright selection colour (this problem exist to some degree also in the current state of Flatty dark).

I saw that now the status bar icons are colourized according to the text colour, is this something planned to be implemented throughout the interface? Being able to select different colours for active / non-active buttons would resolve most of the problems.

I've just compiled blender with a decreased size version of your icons (I tried 80% of the originals, it may be too much but I don't really know) @jendrzych and everything looks way better in my opinion. ![000612.png](https://archive.blender.org/developer/F3854587/000612.png) There may be a couple of icons that would need a small adjustment, but overall they seems fine to me. I have a concern about the design though, I like flat and shadeless stuff, but that comes with quite a big problem: having the icons solid white while having no outline makes it impossible to use a bright theme or a bright selection colour (this problem exist to some degree also in the current state of Flatty dark). I saw that now the status bar icons are colourized according to the text colour, is this something planned to be implemented throughout the interface? Being able to select different colours for active / non-active buttons would resolve most of the problems.
Member

@a.monti
This is not the way to go. 80% size of originals means shrinking icons from 16x16 to 12x12 pixels. It's not so easy, even though effective size of current icons is similar (14x14 with 1pix black outline), because 2.5 pictograms make intensive use of shadows, higlights, while flat design must use just one colour for fills and lines; to achieve cleariness, some white space between different parts ofi icon has to be preserved. In 2.5 symbols 3x3pix detail is easy, but in monoicons it has to be filled poligon to maintain clarity and filled items are preserved for strong accents (Objects) - common pictograms must stay hollow and it consumes space. Every icon has to be razor sharp, and thus every bit needs to be designed pixelwise from scratch. I don't know if I had enough time and power to do that again :( Several dozens of hours of work to do...

@a.monti This is not the way to go. 80% size of originals means shrinking icons from 16x16 to 12x12 pixels. It's not so easy, even though effective size of current icons is similar (14x14 with 1pix black outline), because 2.5 pictograms make intensive use of shadows, higlights, while flat design must use just one colour for fills and lines; to achieve cleariness, some white space between different parts ofi icon has to be preserved. In 2.5 symbols 3x3pix detail is easy, but in monoicons it has to be filled poligon to maintain clarity and filled items are preserved for strong accents (Objects) - common pictograms must stay hollow and it consumes space. Every icon has to be razor sharp, and thus every bit needs to be designed pixelwise from scratch. I don't know if I had enough time and power to do that again :( Several dozens of hours of work to do...

Added subscriber: @jpthrash

Added subscriber: @jpthrash

It's a shame to waste @jendrzych consistent icon work for not wanting to adjust the necessary button padding to accommodate the 16px pictograms. I hope you guys reconsider the idea.

It's a shame to waste @jendrzych consistent icon work for not wanting to adjust the necessary button padding to accommodate the 16px pictograms. I hope you guys reconsider the idea.

Added subscriber: @FilipMond

Added subscriber: @FilipMond

I don't know if this discussion about icon size and sharpens based on pixel precise make any sense. Blender's "User preferences" has "Interface > Display > Scale" function. Icons can be any size. Doesn't matter if they are 12 or 16 or 32 (or whatever). The only one thing that can be taken into account by developers is space around each icon (%), so they are not visually merged.

I don't know if this discussion about icon size and sharpens based on pixel precise make any sense. Blender's "User preferences" has "Interface > Display > Scale" function. Icons can be any size. Doesn't matter if they are 12 or 16 or 32 (or whatever). The only one thing that can be taken into account by developers is space around each icon (%), so they are not visually merged.

These icons, because they use single pixel lines, can only be scaled well at certain increments. They work well with retina displays @2x too, but probably not so much @1.3x

These icons, because they use single pixel lines, can only be scaled well at certain increments. They work well with retina displays @2x too, but probably not so much @1.3x

Added subscriber: @renderhjs

Added subscriber: @renderhjs
Member

@Filip Mond (vklidu)
Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get.

@Filip Mond (vklidu) Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get.

Added subscriber: @JRodrigues

Added subscriber: @JRodrigues

Personally, I think the UI would look great with the 16x16 icons, and no buttons (no outline).

Personally, I think the UI would look great with the 16x16 icons, and no buttons (no outline).

Here's a test with the new icons and outlines of buttons mostly removed:

Old Icons New Icons
old_icons.png new_icons.png

It helps and I like a UI that gets out of the way more by avoiding colors, but there are significant usability issues:

  • The outliner is much harder to read than before, it's not clear to me how to solve this without colors
  • The properties editor tabs are difficult to distinguish at a glance
  • Does this icon set work for light or middle gray themes?
  • Making it required for all themes to have no outlines is not a decision to take lightly, not everyone has great eyesight

There are trade-offs with any design, but we also have to be pragmatic. If this is going to be accepted at some point in the next few months or in a future release, the designers / developers who want this to go forward will need to take the responsibility to address the various issues that inevitably come with a major change like this, and if not argue why it's an acceptable trade-off. Show mockups or tests of how it should look like in a full Blender UI, with different theme colors. At the moment this does not look like a drop in replacement for our current icons, and if it's going to take development time to reorganize the UI, we need to understand the scope so that we can plan it or postpone it.

Here's a test with the new icons and outlines of buttons mostly removed: |Old Icons|New Icons| | -- | -- | |![old_icons.png](https://archive.blender.org/developer/F3856693/old_icons.png)|![new_icons.png](https://archive.blender.org/developer/F3856694/new_icons.png)| It helps and I like a UI that gets out of the way more by avoiding colors, but there are significant usability issues: * The outliner is much harder to read than before, it's not clear to me how to solve this without colors * The properties editor tabs are difficult to distinguish at a glance * Does this icon set work for light or middle gray themes? * Making it required for all themes to have no outlines is not a decision to take lightly, not everyone has great eyesight There are trade-offs with any design, but we also have to be pragmatic. If this is going to be accepted at some point in the next few months or in a future release, the designers / developers who want this to go forward will need to take the responsibility to address the various issues that inevitably come with a major change like this, and if not argue why it's an acceptable trade-off. Show mockups or tests of how it should look like in a full Blender UI, with different theme colors. At the moment this does not look like a drop in replacement for our current icons, and if it's going to take development time to reorganize the UI, we need to understand the scope so that we can plan it or postpone it.

Added subscriber: @gobb_blend

Added subscriber: @gobb_blend

Brecht: Completely agree here.

To make them a drop-in replacement, I think we will need some way to add color to the icons. This could be built-in to the icon, or maybe ideally as part of the theme.
Also, the oblique cube design runs too close to the edges of buttons, and is parallel, which makes it hard to distinguish. Some of them are simply slightly too big to fit nicely within the size of the UI widgets we use currently. This creates a problem with negative space around the icons.

To demonstrate this, I've created two dummy icons that both fit within a certain size. The one on the left fills out the area completely, but leaves no negative space around it, and the lines are parallel to the button edges, causing a visual clash if put too close. The icon on the right also fills the area, but has negative space in the corners, which makes it easier to identify, and easier to read.
Screen Shot 2018-07-03 at 21.02.12.png

I like the general direction of these icons - esp for the simple, genereal UI chrome stuff, such as X, +, - search loupe, disclosure triangles etc, is a clean win.

Some of the more advanced icons for more specific areas, however, such as modifiers and outliner items, seem to lose some quick readability without adjustments to sizing and colors.

Brecht: Completely agree here. To make them a drop-in replacement, I think we will need some way to add color to the icons. This could be built-in to the icon, or maybe ideally as part of the theme. Also, the oblique cube design runs too close to the edges of buttons, and is parallel, which makes it hard to distinguish. Some of them are simply slightly too big to fit nicely within the size of the UI widgets we use currently. This creates a problem with negative space around the icons. To demonstrate this, I've created two dummy icons that both fit within a certain size. The one on the left fills out the area completely, but leaves no negative space around it, and the lines are parallel to the button edges, causing a visual clash if put too close. The icon on the right also fills the area, but has negative space in the corners, which makes it easier to identify, and easier to read. ![Screen Shot 2018-07-03 at 21.02.12.png](https://archive.blender.org/developer/F3857214/Screen_Shot_2018-07-03_at_21.02.12.png) I like the general direction of these icons - esp for the simple, genereal UI chrome stuff, such as X, +, - search loupe, disclosure triangles etc, is a clean win. Some of the more advanced icons for more specific areas, however, such as modifiers and outliner items, seem to lose some quick readability without adjustments to sizing and colors.

Added subscriber: @Loner-2

Added subscriber: @Loner-2

I agree with the Brecht Van Lommel (brecht), that not everyone has excellent vision to look at the icons. And even if the color old icons are not unified, but they are distinguishable and clear in both light and dark interface themes. So I'd like to keep the old icons version ,but not icons, which new type of white.

I agree with the Brecht Van Lommel (brecht), that not everyone has excellent vision to look at the icons. And even if the color old icons are not unified, but they are distinguishable and clear in both light and dark interface themes. So I'd like to keep the old icons version ,but not icons, which new type of white.

Maybe these large new icons would "pop" a bit less in this dark theme if they were a bit grey, instead of pure white, especially in the outliner.

Maybe these large new icons would "pop" a bit less in this dark theme if they were a bit grey, instead of pure white, especially in the outliner.
Member

@WilliamReynish
I changed axonometry type because of supposed future change in Toolbar icons, You've showed me some time ago. It's not a big problem to bring old axonometry icons back - they're backed up. I can try to redesign the set from scratch, but it will take some significant amount of time, and it would be really helpful to get some kind of temporal solution that would allow changing raster icon set without building app anytime I tweak sth in an icon.

Regarding the colour - as I stated many times before in my topic at blenderartists.org, this project focuses on shapes first of all. When we'll reach the point where all silhouettes work, then colour can be added and it can be done in several diferent ways - this is open topic. One of main goals of the design I'm working on is to make icons style/guidelines simpler for other designers to follow. Current set is hard as hell to mimic, even for me... So, shapes first, simple'n'flat colour codes next.

P.S. I think, that long lists of items, such as the one occupied by Modifiers, must be iconless. Pictograms doesn't help much in such massive stacks. Another question is the fact that's really hard to design so many tiny icons that are different enough from eachother. Mostly it's a problem of organisation of the list IMHO. Simple search function would be a blessing in such places.
Modifiers_mock_3.png

Some say that icons can help here, but apparently not that much IMHO:
Modifiers_mock_1.png

@WilliamReynish I changed axonometry type because of supposed future change in Toolbar icons, You've showed me some time ago. It's not a big problem to bring old axonometry icons back - they're backed up. I can try to redesign the set from scratch, but it will take some significant amount of time, and it would be really helpful to get some kind of temporal solution that would allow changing raster icon set without building app anytime I tweak sth in an icon. Regarding the colour - as I stated many times before in my topic at blenderartists.org, this project focuses on shapes first of all. When we'll reach the point where all silhouettes work, then colour can be added and it can be done in several diferent ways - this is open topic. One of main goals of the design I'm working on is to make icons style/guidelines simpler for other designers to follow. Current set is hard as hell to mimic, even for me... So, shapes first, simple'n'flat colour codes next. P.S. I think, that long lists of items, such as the one occupied by Modifiers, must be iconless. Pictograms doesn't help much in such massive stacks. Another question is the fact that's really hard to design so many tiny icons that are different enough from eachother. Mostly it's a problem of organisation of the list IMHO. Simple search function would be a blessing in such places. ![Modifiers_mock_3.png](https://archive.blender.org/developer/F3857775/Modifiers_mock_3.png) Some say that icons can help here, but apparently not that much IMHO: ![Modifiers_mock_1.png](https://archive.blender.org/developer/F3857778/Modifiers_mock_1.png)

I generally like the direction Andrzej Ambroz work is taking, keep up the excellent work.

In #53840#515475, @WilliamReynish wrote:
I think we will need some way to add color to the icons.

I wonder if some sort of system that used RGB color channels as masks would be feasible.

If we could agree on some type of "threefold color code system" where there would be a "main" color and two secondary "highlight" colors used across all icons, maybe we could establish sensible rules to highlight key elements of the pictograms (like actions, animations, tools, shading, families or groups, among others), using the same three colors consistently across all icons.

Since icons are mostly monochrome flat by designed, and we only need one color channel+Alpha to represent them correctly. Maybe the remaining green and blue channels could then be repurposed in a some sort of mask system where colors would be read at runtime from the current theme and overlayed according to the pixel values of each channel. Red could correspond to the "main" icon color (in this case it would be white but), for lighter themes it could be some shade of darker gray or black, always configurable from the theme to be as readable as desired.

I generally like the direction Andrzej Ambroz work is taking, keep up the excellent work. > In #53840#515475, @WilliamReynish wrote: > I think we will need some way to add color to the icons. I wonder if some sort of system that used RGB color channels as masks would be feasible. If we could agree on some type of "threefold color code system" where there would be a "main" color and two secondary "highlight" colors used across all icons, maybe we could establish sensible rules to highlight key elements of the pictograms (like actions, animations, tools, shading, families or groups, among others), using the same three colors consistently across all icons. Since icons are mostly monochrome flat by designed, and we only need one color channel+Alpha to represent them correctly. Maybe the remaining green and blue channels could then be repurposed in a some sort of mask system where colors would be read at runtime from the current theme and overlayed according to the pixel values of each channel. Red could correspond to the "main" icon color (in this case it would be white but), for lighter themes it could be some shade of darker gray or black, always configurable from the theme to be as readable as desired.

@jendrzych Modifier list without icons +1 for me (faster to scan). I wasn't sure about properties panel, but from this gif example still looks like good way.

GIF - original / proposed modifier list to unified system / text only

test_Modifier-list-icon.gif

I was thinking about the same, just in a way more radical :) When I see the list of needed icons – isn't it better to delete any icon represented already by text? And keep icons only for cases where text is not possible (wanted)?
There are cases like like Editor list, that looks easier to read only text (no icons), but without icon I'm not sure if its enough for new user to select by text and than see icon only in a corner of editor window.

GIF - original / monoicons / tinted / text only

test_Icons+Text.gif

Ignore mono icons shape, just for illustration, (specially blue was quick hack).

To iconise everything is not a solution. Like this proposal https://developer.blender.org/T38656 - I don't think it helps (probably in case you want to keep only icons, but also in that case seems to me easier understand to text, than think what icons represent).

@jendrzych Modifier list without icons +1 for me (faster to scan). I wasn't sure about properties panel, but from this gif example still looks like good way. **GIF** - original / proposed modifier list to unified system / text only ![test_Modifier-list-icon.gif](https://archive.blender.org/developer/F3861848/test_Modifier-list-icon.gif) I was thinking about the same, just in a way more radical :) When I see the list of needed icons – isn't it better to delete any icon represented already by text? And keep icons only for cases where text is not possible (wanted)? There are cases like like Editor list, that looks easier to read only text (no icons), but without icon I'm not sure if its enough for new user to select by text and than see icon only in a corner of editor window. **GIF** - original / monoicons / tinted / text only ![test_Icons+Text.gif](https://archive.blender.org/developer/F3861836/test_Icons_Text.gif) Ignore mono icons shape, just for illustration, (specially blue was quick hack). To iconise everything is not a solution. Like this proposal https://developer.blender.org/T38656 - I don't think it helps (probably in case you want to keep only icons, but also in that case seems to me easier understand to text, than think what icons represent).

Maybe we could have the Editor list without icons, and the icons individually appear when we mouse hover over the text.

Maybe we could have the Editor list without icons, and the icons individually appear when we mouse hover over the text.

In #53840#515263, @WilliamReynish wrote:
These icons, because they use single pixel lines, can only be scaled well at certain increments. They work well with retina displays @2x too, but probably not so much @1.3x

In #53840#515326, @jendrzych wrote:
@Filip Mond (vklidu)
Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get.

In theory I definitely agree, there is nothing to argue. But to keep "crystal" sharpness of pixel based icons you need to fix their size or give user ability to scale them in predefined steps. Like now user will set what ever value, just make them bigger or smaller. How many of them will care if they divide them equally? In reality it is always about dividing some amount of pixels, from that point of view doesn't matter if you divide icon 12x12 or 16x16 :)

For me UI set to 1 is too small on my 27inch screen I use 1.2 or 1.4 so I'm off :) , but I never had a problem with this kind of "unsharpness".
It was already discussed that default size "1" is small for most of the users (always hard t say what is the most, probably there is much bigger group of user that is quietly sitting satisfied with current size :).

Note to use outline as space - 2px wither space (without outline) doesn't help to read icons - like in properties header. It helps current 2.5 icons to be read better (not to the new jendrzch's one).

> In #53840#515263, @WilliamReynish wrote: > These icons, because they use single pixel lines, can only be scaled well at certain increments. They work well with retina displays @2x too, but probably not so much @1.3x > In #53840#515326, @jendrzych wrote: > @Filip Mond (vklidu) > Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get. In theory I definitely agree, there is nothing to argue. But to keep "crystal" sharpness of pixel based icons you need to fix their size or give user ability to scale them in predefined steps. Like now user will set what ever value, just make them bigger or smaller. How many of them will care if they divide them equally? In reality it is always about dividing some amount of pixels, from that point of view doesn't matter if you divide icon 12x12 or 16x16 :) For me UI set to 1 is too small on my 27inch screen I use 1.2 or 1.4 so I'm off :) , but I never had a problem with this kind of "unsharpness". It was already discussed that default size "1" is small for most of the users (always hard t say what is the most, probably there is much bigger group of user that is quietly sitting satisfied with current size :). Note to use outline as space - 2px wither space (without outline) doesn't help to read icons - like in properties header. It helps current 2.5 icons to be read better (not to the new jendrzch's one).
Member

Now - to shrink icons, or not to shrink? That is a question!
skull - hollow'n'full.png

Now - to shrink icons, or not to shrink? That is a question! ![skull - hollow'n'full.png](https://archive.blender.org/developer/F3865075/skull_-_hollow_n_full.png)

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
William Reynish self-assigned this 2018-10-01 23:21:49 +02:00

Removed subscriber: @gobb_blend

Removed subscriber: @gobb_blend

Added subscriber: @RomboutVersluijs

Added subscriber: @RomboutVersluijs

That guideline article in the resources at the top is really a great detail.

I do like the minimal icons and the dark version. Yet i do now see this can cause big issue looking at that example @brecht made

That guideline article in the resources at the top is really a great detail. I do like the minimal icons and the dark version. Yet i do now see this can cause big issue looking at that example @brecht made
Member

Added subscriber: @blend-it

Added subscriber: @blend-it
Member

I prefer much more current icons instead monochromatic and flat.

I prefer much more current icons instead monochromatic and flat.

Added subscriber: @AdamPreisler

Added subscriber: @AdamPreisler

In #53840#505679, @jendrzych wrote:

in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.

I guesss I'm in the minority here to believe this is .. not correct? I always prefer icons that have colors because that makes them much easier to recognize. Also when you tell beginners "just click on the slightly red sphere" they always click correctly on the material tab in properties windows for example.

Mono and flat might look good in practice but it is of course less powerful..

There is a reason why humans see color. Also since the UI is in essence flat, why should the icons be also flat? So that they blend with the background?

> In #53840#505679, @jendrzych wrote: > # in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items. I guesss I'm in the minority here to believe this is .. not correct? I always prefer icons that have colors because that makes them much easier to recognize. Also when you tell beginners "just click on the slightly red sphere" they always click correctly on the material tab in properties windows for example. Mono and flat might look good in practice but it is of course less powerful.. There is a reason why humans see color. Also since the UI is in essence flat, why should the icons be also flat? So that they blend with the background?

@AdamPreisler: Colors will now be handled by the theme, not the icon glyph. This has many advantages - it makes them readable on both bright and dark themes, and it makes it possible to customize their colors to be strong or subtle.

Most likely we will flesh this out more, so colors can be used to identify items more easily. We already do this in the Outliner, where the theme gives the icons different colors for different types of data.

@AdamPreisler: Colors will now be handled by the theme, not the icon glyph. This has many advantages - it makes them readable on both bright and dark themes, and it makes it possible to customize their colors to be strong or subtle. Most likely we will flesh this out more, so colors can be used to identify items more easily. We already do this in the Outliner, where the theme gives the icons different colors for different types of data.

@WilliamReynish That's great news. Amazingly great news^^ Application template ready. So does this mean we could change color per icon if needed?
I will probably tune mine in Properties menu to corresond with the current general set of colors / greys.

Is the process from svg to Blender automated or is there a lot of manual work to split icons etc into seperate files?

I see this customizability of Blender pretty great for application templates as they will most likely want to "grey" out a lot of stuff or even introduce new icons of their own.

The Properties window is absolutely most icon reliant as it's one of the rare cases where there's so much different stacked into text-less tab menu.

Just throwing that out there as I haven't realized it previously.

When explaining I always say:
"the camera on the left" (render options)
"the blue wrench" (modifiers)
"the slightly red sphere" (materials)
"the blue sphere on the left" (world)
"the triangle" (mesh data)
"the movie camera" (camera data)
"the yellow light icon" (lamp data)
**"the orange cube" ** (object data)

I know a lot of these are still kind of recognizable but to me, the different colors always meant a lot.

World (Environment) = BlueGreen Earth
Lamp = Yellow
Object = Orange
Modifier = Blue
Materials = Red
Camera = Is grey but could be purple and also purple in the viewport by default? (people have trouble finding it if it blends with the rest)

Like so:

Theme_Colors_for_Special_Objects.gif

Surprisingly one that I had most trouble with and I misclick often is Render Layer and Scene.. But not so much anymore.. but the rest weren't a problem in distinguishing.

@WilliamReynish That's great news. Amazingly great news^^ Application template ready. So does this mean we could change color per icon if needed? I will probably tune mine in Properties menu to corresond with the current general set of colors / greys. Is the process from svg to Blender automated or is there a lot of manual work to split icons etc into seperate files? I see this customizability of Blender pretty great for application templates as they will most likely want to "grey" out a lot of stuff or even introduce new icons of their own. **The Properties window is absolutely most icon reliant as it's one of the rare cases where there's so much different stacked into text-less tab menu.** Just throwing that out there as I haven't realized it previously. When explaining I always say: **"the camera on the left"** (render options) **"the blue wrench"** (modifiers) **"the slightly red sphere"** (materials) **"the blue sphere on the left"** (world) **"the triangle"** (mesh data) **"the movie camera"** (camera data) **"the yellow light icon"** (lamp data) **"the orange cube" ** (object data) I know a lot of these are still kind of recognizable but to me, the different colors always meant a lot. World (Environment) = BlueGreen Earth Lamp = Yellow Object = Orange Modifier = Blue Materials = Red Camera = Is grey but could be purple and also purple in the viewport by default? (people have trouble finding it if it blends with the rest) Like so: ![Theme_Colors_for_Special_Objects.gif](https://archive.blender.org/developer/F3545515/Theme_Colors_for_Special_Objects.gif) Surprisingly one that I had most trouble with and I misclick often is Render Layer and Scene.. But not so much anymore.. but the rest weren't a problem in distinguishing.

Added subscriber: @0o00o0oo

Added subscriber: @0o00o0oo

Added subscriber: @OdinFernandezMoreno

Added subscriber: @OdinFernandezMoreno

Removed subscriber: @OdinFernandezMoreno

Removed subscriber: @OdinFernandezMoreno
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
33 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#53840
No description provided.