Blender Icon Guidelines #38757

New Issue

Peter Varo · 2014-02-22T16:18:45+01:00

Peter Varo commented

2014-02-22 16:18:45 +01:00

Blender Icon Guidelines

Separate SVG files

Blender uses vector graphic icons on its user interface. Since itself is an open source software, it uses an open standard image format: the W3C approved Scalable Vector Graphics, which is basically a namespaced XML dialect. At the moment blender has a single huge SVG file which is processed and separated during compilation time.

Why isn't the single-file model and the compilation time processing is not good?

First of all, SVG is a very powerful format. Even though it is having its renaissance on the web as we completely replace Flash with other technologies such as HTML5, CSS3 and JS, it is still a really old solution and lacking dozens of new and preferred features. And although it has solid and amazing proposals for its next version (2.0), those suggestions are in this proposal-state since ages. I think that is one of the reasons, why most of the vector drawing utilities and applications has different implementations to improve and extend SVG with their existing but currently unavailable features in version 1.1; or absolutely new ideas to SVG.

Probably this isn't a big problem on its own, especially not if a dedicated, closed team with a specific toolset is working on the interface of blender. But this is clearly not the case, and as a matter of fact a lot of people wants to contribute and collaborate on the UI. And those people have different operating systems, therefore different applications and licenses, therefore different SVG compatibilities. This the first problem we have with this single file of icons. If someone opens and probably makes some changes and save this file, it has a great chance that this saving will effect the other icons as well! This is clearly a thing we don't want!

The second problem we are facing with this single file of icons is that it is truly difficult to follow, which icons are used in more than one places; what are the names of a specific set of icons or even a single icon; how to search in the icons; how to use those icons while creating a mock-up, etc. And unfortunately this file is getting bigger and bigger over time. (This is a good thing it means there are going to be new icons available in blender, but also means it will be really hard to maintain those.)

The third problem is if some user wants to have custom icons. Let's just assume this user doesn't want completely different ones, but a recolored set of icons to match with the users color settings of the selection or the panels in blender. Clearly, this case one has to change this single file and recompile a new version of blender with the changed SVG. This "static" solution is a pain in the arse, and makes the changing almost impossible. (And I did not mention the "official" designer team here -- it's quite difficult to test the new icons!)

Proposal to use separate image files and style presets

First of all, we need to make blender's SVG loading and processing to work on runtime. Most likely it will load the icons on startup or after a refresh/reload command is called in the console.

Second, we need a list of references of the separate SVG icons, which for example can be browsed, modified and extended without changing the actual icon file.

My proposal is that we should use JSON (JavaScript Object Notation) for this purpose, since it is super-lightweight, really easy to parse and write from any programming language because it's object structure is natively available in most of them. It is also easy to read and write for human beings. Here is a version how I imagine it would look like:

  lang=json, name=blender_icons_list.json
  {
      "ObjectMode":
      {
          "ToolsTab":
          {
              "Transform":
              {
                  "Translate": "release/datafiles/icons/fx/Move.svg",
                  "Rotate"   : "release/datafiles/icons/fx/Rotate.svg",
                  "Scale"    : "release/datafiles/icons/fx/Scale.svg",
                  "Mirror"   : "release/datafiles/icons/fx/Mirror.svg"
              },
              "Edit":
              {
                  "Duplicate"      : "release/datafiles/icons/fx/Dup.svg",
                  "DuplicateLinked": "release/datafiles/icons/fx/DupLink.svg",
                  "Join"           : "release/datafiles/icons/fx/Join.svg",
                  "Delete"         : "release/datafiles/icons/fx/Del.svg"
              }
          }
      },
      "EditMode":
      {
          "ToolsTab":
          {
              "Transform":
              {
                  "Translate"     : ["ObjectMode", "ToolsTab", "Transform", "Translate"],
                  "Rotate"        : ["ObjectMode", "ToolsTab", "Transform", "Rotate"],
                  "Scale"         : ["ObjectMode", "ToolsTab", "Transform", "Scale"],
                  "Shrink/Flatten": "release/datafiles/icons/fx/ShrinkF.svg",
                  "Push/Pull"     : "release/datafiles/icons/fx/PushPull.svg"
              },
          }
      }
  }

As you can see, it is very-well structured, and easy to navigate inside it. I also propose a "linking" feature, which means if the value of a key is a list, it will lead to the location of a pre-existing icon. With this method it became very simple for a designer to link one image file to another area of the GUI with the same functionality.

Style presets to uniform icons

Although SVG has a very awesome feature to make the existing code-base reusable, it is limited to a single file only. One cannot separate the definitions of filters and gradients and import them or refer to them from another SVG file. So it would be really nice to have a DRY and globally controlled style-sheet which stores the presets. For example, if one wants to change the "selection" color in each icon from the default "orange" to "cyan", because ones color preferences in blender uses this different color. Or one wants to make the icons darker or even brighter not only because one wants to match ones panel color settings, but because the icons will be easier to recognise and less aggressive to look at (less contrasts makes it more comfortable to look at for a long time). Or as a blender designer one also wants to globally change a color setting to try new approaches for all icons.

As you can imagine, this kind of work is very tedious and boring to do: open each file (and we are talking about at least 300 icons!); find the objects you want to change the color of; apply the new settings; save it; and close it and start the whole process again.

However SVG has special CSS support, it can only apply pre-existing filters to the SVG elements, it cannot build new ones, and also cannot copy definitions from one file to another -- well, CSS is only a declarative language as we all know.

That's why I implemented a small script in Python apply_icon_theme.py which reads a JSON definition file; also scans the JSON list file mentioned above; and applies all the details described in the definition file to the separate SVG files. All I have to do is carefully pick the right "reference" names to my objects.

How this is working in action (example)

Let's say we have these icons:

{F78378, float, size=full}{F78380, float, size=full}{F78367, float, size=full}{F78372, size=full}

{F78362 float}

As we can see, both of the files are using some kind of orange color, but they are not matching. Plus, they need inner shadows to make them look 3D. They are defining gradients with inapposite colors but what is important for us at the moment is that they are at least describing the directions and the gradient locations.

So I open the SVG files in a text editor, and start editing them. I have to do this step only once after the drawing stage, and now on I can change the exact values any time I want. So I add these few lines and rename the gradient in the <defs> section:

  lang=xml, name=part of example1.svg
  <defs>
      <linearGradient id="selected_fill_solid" />
      <linearGradient id="selected_outline_solid" />
      <filter id="example_body_shadow" />
      <filter id="example_drop_shadow" />
      <linearGradient id="selected_fill_gradient" gradientUnits="userSpaceOnUse" x1="4.037" y1="6.012" x2="11.988" y2="6.012">
        <stop offset="0" stop-color="#FFFFFF"/>
        <stop offset="1" stop-color="#000000"/>
      </linearGradient>
  <defs>

And of course I link the definition IDs to the actual objects. I don't have to specify any other details, such as colors or other sub elements.

I create/modify the definition JSON file:

  lang=json, name=blender_icon_theme.json
  {
      "---------------------------- VARIABLES -----------------------------": "#",
      "almost_white_orange": "#FFE9BE",
      "light_orange": "#FFCC66",
      "mid_orange"  : "#A3671C",
      "dark_orange" : "#804000",

      "--------------------------- SOLID COLORS ---------------------------": "#",

      "selected_outline_solid": { "color": "@dark_orange" },
      "selected_fill_solid"   : { "color": "@light_orange" },

      "-------------------------- GRADIENT COLORS -------------------------": "#",

      "selected_fill_gradient"  :
      [
          { "color": "@light_orange", "stop": 0 },
          { "color": "@dark_orange",  "stop": 0.7 },
          { "color": "@mid_orange",   "stop": 1 }
      ],

      "--------------------------- SHADOW VALUES --------------------------": "#",

      "example_drop_shadow":
      [
          {
              "type"    : "outer",
              "blur"    : [0.5, 1],
              "offset"  : [0, 0.5],
              "opacity" : 0.7
          }
      ],
      "example_body_shadow":
      [
          {
              "----- HIGHLIGHT -----": "#",
              "type"    : "inner",
              "color"   : "@almost_white_orange",
              "blend"   : "screen",
              "blur"    : [0.1, 0.5],
              "offset"  : [0, 1],
              "opacity" : 0.35
          },
          {
              "----- HARD SHADOW -----": "#",
              "type"    : "inner",
              "color"   : "@dark_orange",
              "blend"   : "multiply",
              "blur"    : [0.5, 1],
              "offset"  : [0, -3],
              "opacity" : 0.7
          },
          {
              "----- REFLECTION -----": "#",
              "type"    : "inner",
              "color"   : "@almost_white_orange",
              "blend"   : "screen",
              "blur"    : [0.1, 0.5],
              "offset"  : [0, -1],
              "opacity" : 0.2
          }
      ]
  }

Now I navigate to the python file and run it:

  lang=bash, name=terminal command
  >>> python3 apply_icon_theme.py

And voilá! I have the "unified" final versions here:

{F78388, float, size=full}{F78390, float, size=full}{F78383, float, size=full}{F78385, size=full}

{F78392 float} example2_final.svg

Detailed Instructions

Reference presets in SVG

Solid Colors, Linear and Radial Gradients

One can define solid colors by simply adding a <linearGradient>s with a defined id to the <defs> section, like:

  lang=xml, name=add naked references
  <defs>
      <linearGradient id="selected_outline" />
      <linearGradient id="selected_fill" />
  </defs>

and then one can apply these colors to take effect on the selected objects:

  lang=xml, name=connect definitions to actual objects
  <g id="Layer 1"
      <path d="M10,10 L90,10 L90,90 L10,90 z fill="url(#selected_outline)" />
      <path d="M15,15 L85,15 L85,85 L15,85 z fill="url(#selected_fill)" />
  </g>

NOTE: if you want to add "real" gradients, you also have to define the details of the gradient, like: <linearGradient id="selected_fill_gradient" gradientUnits="userSpaceOnUse" x1="10" x2="5" y1="-15" y2="-15" />

Shadows

Adding shadows/glows is not harder at all one has to add a <filter>s with a defined id to <defs> section, like:

  lang=xml, name=add naked references
  <defs>
      <filter id="outline_outer_shadow" />
      <filter id="simple_inner_shadow" />
  </defs>

and then apply this color to the object you want to use for example:

  lang=xml, name=connect definitions to actual objects
  <g id="Layer 1"
      <path d="M10,10 L90,10 L90,90 L10,90 z filter="url(#outline_outer_shadow)" />
      <path d="M15,15 L85,15 L85,85 L15,85 z filter="url(#simple_inner_shadow)" />
  </g>

Implement presets in JSON

NOTE: in this section the values between comparison signs <type: value> indicates what kind of input is expected or which one has default value. Because JSON uses [ and ] characters for arrays, this documentation uses ( and ) characters to indicate which values are optional.

Comments

A well structured declarative file needs comments too, but since JSON does not support comments and because I wanted to keep the file as close to the standard as I can, I come up with this solution::

  <string: literal block>: "#"

Because only those key-value pairs will be detected as comments which values are equal to "#", it is allowed to add as many comment lines as wanted inside the same scope. Comments are recursively removed before the JSON file is processed.

Variables

A maintainable declaration needs variables as well, to make it even easier to change with as little effort as possible. One can create variables, assign values to them and use them later on in the JSON file. A variable can hold any kind of JSON data. The assignment is really simple:

  <string: variable name>: <any: data>

Referring to a variable needs a @ prefix:

  <property>: "@<variable name>"

NOTE: At the moment there is no circular-reference checking! So it is quite easy to get a RuntimeError: maximum recursion depth exceeded in Python.

Colors and Gradients

To define a solid-color one can use a single dictionary:

  <id>:
  {
      "color"      : <string: hexadecimal, default=0>
      (, "opacity" : <float: 0-1, default=1> )
  }

Gradients are list of color-dictionaries, but these colors also have a stop value:

  <id>:
  [
      {
          "color"      : <string: hexadecimal, default=0>
          "stop"       : <float: 0-1>
          (, "opacity" : <float: 0-1, default=1> )
      },
      {
          "color"      : <string: hexadecimal, default=0>
          "stop"       : <float: 0-1>
          (, "opacity" : <float: 0-1, default=1> )
      }
  ]

NOTE: Each gradient stop value is required to be equal to or greater than the previous gradient stop's value. If a given gradient stop's value is not equal to or greater than all previous stop values, then the stop value is adjusted to be equal to the largest of all previous stop values.

Shadow filters

One can define inner and outer drop shadows as well:

  <id>:
  [
      {
          "type"       : <string: inner|outer>
          (, "color"   : <string: hexadecimal, default=#000000> )
          (, "blur"    : [ <float: 0-1, default=0> (, <float: 0-1, default=0>) ] )
          (, "offset"  : [ <float: 0-1> (, <float: 0-1, default=0>) ] )
          (, "opacity" : <float: 0-1, default=1> )
          (, "blend"   : <string: normal|multiply|screen, default=norma> )
      }
  ]

The first value of blur's' or offset's' list is responsible for the x-direction and the second value is for the y-direction. If only one value is provided in the list, the second value will be equal to the first one.

NOTE: Glow effects are special cases of inner/outer shadows with zero offsets on each directions.

NOTE: After I will use this system in real-life situations, it is possible, that I will refine it, or extend it with some new filters and settings, so it will be a constantly evolving solution for the designers.

Next Chapter: what shapes and dimensions are preferred to get the best vector -> raster icon?

# Blender Icon Guidelines ## Separate SVG files Blender uses vector graphic icons on its user interface. Since itself is an open source software, it uses an open standard image format: the W3C approved Scalable Vector Graphics, which is basically a namespaced XML dialect. At the moment blender has a single *huge* SVG file which is *processed* and *separated* during compilation time. **Why isn't the *single-file model* and the *compilation time processing* is not good?** First of all, SVG is a very powerful format. Even though it is having its renaissance on the web as we completely replace Flash with other technologies such as HTML5, CSS3 and JS, it is still a really old solution and lacking dozens of new and preferred features. And although it has solid and amazing proposals for its next version (2.0), those suggestions are in this *proposal-state* since ages. I think that is one of the reasons, why most of the vector drawing utilities and applications has different implementations to improve and extend SVG with their existing but currently unavailable features in version 1.1; or absolutely new ideas to SVG. Probably this isn't a big problem on its own, especially not if a dedicated, closed team with a specific toolset is working on the interface of blender. But this is clearly not the case, and as a matter of fact a lot of people wants to contribute and collaborate on the UI. And those people have different operating systems, therefore different applications and licenses, therefore different SVG compatibilities. This the first problem we have with this *single file of icons*. If someone opens and probably makes some changes and save this file, it has a great chance that this saving will effect the other icons as well! This is clearly a thing we don't want! The second problem we are facing with this *single file of icons* is that it is truly difficult to follow, which icons are used in more than one places; what are the names of a specific set of icons or even a single icon; how to search in the icons; how to use those icons while creating a mock-up, etc. And unfortunately this file is getting bigger and bigger over time. (This is a good thing it means there are going to be new icons available in blender, but also means it will be really hard to maintain those.) The third problem is if some user wants to have custom icons. Let's just assume this user doesn't want completely different ones, but a recolored set of icons to match with the users color settings of the selection or the panels in blender. Clearly, this case one has to change this single file and recompile a new version of blender with the changed SVG. This "static" solution is a pain in the arse, and makes the changing almost impossible. (And I did not mention the "official" designer team here -- it's quite difficult to test the new icons!) **Proposal to use *separate image files* and style presets** First of all, we need to make blender's SVG loading and processing to work on runtime. Most likely it will load the icons on startup or after a refresh/reload command is called in the console. Second, we need a list of references of the separate SVG icons, which for example can be browsed, modified and extended without changing the actual icon file. My proposal is that we should use JSON (JavaScript Object Notation) for this purpose, since it is super-lightweight, really easy to parse and write from any programming language because it's object structure is natively available in most of them. It is also easy to read and write for human beings. Here is a version how I imagine it would look like: ``` lang=json, name=blender_icons_list.json { "ObjectMode": { "ToolsTab": { "Transform": { "Translate": "release/datafiles/icons/fx/Move.svg", "Rotate" : "release/datafiles/icons/fx/Rotate.svg", "Scale" : "release/datafiles/icons/fx/Scale.svg", "Mirror" : "release/datafiles/icons/fx/Mirror.svg" }, "Edit": { "Duplicate" : "release/datafiles/icons/fx/Dup.svg", "DuplicateLinked": "release/datafiles/icons/fx/DupLink.svg", "Join" : "release/datafiles/icons/fx/Join.svg", "Delete" : "release/datafiles/icons/fx/Del.svg" } } }, "EditMode": { "ToolsTab": { "Transform": { "Translate" : ["ObjectMode", "ToolsTab", "Transform", "Translate"], "Rotate" : ["ObjectMode", "ToolsTab", "Transform", "Rotate"], "Scale" : ["ObjectMode", "ToolsTab", "Transform", "Scale"], "Shrink/Flatten": "release/datafiles/icons/fx/ShrinkF.svg", "Push/Pull" : "release/datafiles/icons/fx/PushPull.svg" }, } } } ``` As you can see, it is very-well structured, and easy to navigate inside it. I also propose a *"linking"* feature, which means if the value of a key is a list, it will lead to the location of a pre-existing icon. With this method it became very simple for a designer to link one image file to another area of the GUI with the same functionality. - - - ## Style presets to uniform icons Although SVG has a very awesome feature to make the existing code-base reusable, it is limited to a single file only. One cannot separate the definitions of filters and gradients and import them or refer to them from another SVG file. So it would be really nice to have a DRY and globally controlled style-sheet which stores the presets. For example, if one wants to change the "selection" color in each icon from the default "orange" to "cyan", because ones color preferences in blender uses this different color. Or one wants to make the icons darker or even brighter not only because one wants to match ones panel color settings, but because the icons will be easier to recognise and less aggressive to look at (less contrasts makes it more comfortable to look at for a long time). Or as a blender designer one also wants to globally change a color setting to try new approaches for all icons. As you can imagine, this kind of work is very tedious and boring to do: open each file (and we are talking about at least 300 icons!); find the objects you want to change the color of; apply the new settings; save it; and close it and start the whole process again. However SVG has special CSS support, it can only apply pre-existing filters to the SVG elements, it cannot build new ones, and also cannot copy definitions from one file to another -- well, CSS is only a declarative language as we all know. That's why I implemented a small script in Python [apply_icon_theme.py](http://cl.ly/code/2k2e2223130O) which reads a JSON definition file; also scans the JSON list file mentioned above; and applies all the details described in the definition file to the separate SVG files. All I have to do is carefully pick the right "reference" names to my objects. ## How this is working in action (example) Let's say we have these icons: {[F78378](https://archive.blender.org/developer/F78378/example1_original_1x.png), float, size=full}{[F78380](https://archive.blender.org/developer/F78380/example1_original_2x.png), float, size=full}{[F78367](https://archive.blender.org/developer/F78367/example2_original_1x.png), float, size=full}{[F78372](https://archive.blender.org/developer/F78372/example2_original_2x.png), size=full} {[F78362](https://archive.blender.org/developer/F78362/example1_original.svg) float} ![example2_original.svg](https://archive.blender.org/developer/F78363/example2_original.svg) As we can see, both of the files are using some kind of orange color, but they are not matching. Plus, they need inner shadows to make them look 3D. They are defining gradients with inapposite colors but what is important for us at the moment is that they are at least describing the directions and the gradient locations. So I open the SVG files in a text editor, and start editing them. I have to do this step only once after the drawing stage, and now on I can change the exact values any time I want. So I add these few lines and rename the gradient in the `<defs>` section: ``` lang=xml, name=part of example1.svg <defs> <linearGradient id="selected_fill_solid" /> <linearGradient id="selected_outline_solid" /> <filter id="example_body_shadow" /> <filter id="example_drop_shadow" /> <linearGradient id="selected_fill_gradient" gradientUnits="userSpaceOnUse" x1="4.037" y1="6.012" x2="11.988" y2="6.012"> <stop offset="0" stop-color="#FFFFFF"/> <stop offset="1" stop-color="#000000"/> </linearGradient> <defs> ``` And of course I link the definition IDs to the actual objects. I don't have to specify any other details, such as colors or other sub elements. I create/modify the definition JSON file: ``` lang=json, name=blender_icon_theme.json { "---------------------------- VARIABLES -----------------------------": "#", "almost_white_orange": "#FFE9BE", "light_orange": "#FFCC66", "mid_orange" : "#A3671C", "dark_orange" : "#804000", ``` ``` "--------------------------- SOLID COLORS ---------------------------": "#", ``` ``` "selected_outline_solid": { "color": "@dark_orange" }, "selected_fill_solid" : { "color": "@light_orange" }, ``` ``` "-------------------------- GRADIENT COLORS -------------------------": "#", ``` ``` "selected_fill_gradient" : [ { "color": "@light_orange", "stop": 0 }, { "color": "@dark_orange", "stop": 0.7 }, { "color": "@mid_orange", "stop": 1 } ], ``` ``` "--------------------------- SHADOW VALUES --------------------------": "#", ``` ``` "example_drop_shadow": [ { "type" : "outer", "blur" : [0.5, 1], "offset" : [0, 0.5], "opacity" : 0.7 } ], "example_body_shadow": [ { "----- HIGHLIGHT -----": "#", "type" : "inner", "color" : "@almost_white_orange", "blend" : "screen", "blur" : [0.1, 0.5], "offset" : [0, 1], "opacity" : 0.35 }, { "----- HARD SHADOW -----": "#", "type" : "inner", "color" : "@dark_orange", "blend" : "multiply", "blur" : [0.5, 1], "offset" : [0, -3], "opacity" : 0.7 }, { "----- REFLECTION -----": "#", "type" : "inner", "color" : "@almost_white_orange", "blend" : "screen", "blur" : [0.1, 0.5], "offset" : [0, -1], "opacity" : 0.2 } ] } ``` Now I navigate to the python file and run it: ``` lang=bash, name=terminal command >>> python3 apply_icon_theme.py ``` And *voilá!* I have the "unified" final versions here: {[F78388](https://archive.blender.org/developer/F78388/example1_final_1x.png), float, size=full}{[F78390](https://archive.blender.org/developer/F78390/example1_final_2x.png), float, size=full}{[F78383](https://archive.blender.org/developer/F78383/example2_final_1x.png), float, size=full}{[F78385](https://archive.blender.org/developer/F78385/example2_final_2x.png), size=full} {[F78392](https://archive.blender.org/developer/F78392/example1_final.svg) float} [example2_final.svg](https://archive.blender.org/developer/F78387/example2_final.svg) - - - # Detailed Instructions ## Reference presets in SVG **Solid Colors, Linear and Radial Gradients** One can define solid colors by simply adding a `<linearGradient>`s with a defined `id` to the `<defs>` section, like: ``` lang=xml, name=add naked references <defs> <linearGradient id="selected_outline" /> <linearGradient id="selected_fill" /> </defs> ``` and then one can apply these colors to take effect on the selected objects: ``` lang=xml, name=connect definitions to actual objects <g id="Layer 1" <path d="M10,10 L90,10 L90,90 L10,90 z fill="url(#selected_outline)" /> <path d="M15,15 L85,15 L85,85 L15,85 z fill="url(#selected_fill)" /> </g> ``` NOTE: if you want to add "real" gradients, you also have to define the details of the gradient, like: `<linearGradient id="selected_fill_gradient" gradientUnits="userSpaceOnUse" x1="10" x2="5" y1="-15" y2="-15" />` **Shadows** Adding shadows/glows is not harder at all one has to add a `<filter>`s with a defined `id` to `<defs>` section, like: ``` lang=xml, name=add naked references <defs> <filter id="outline_outer_shadow" /> <filter id="simple_inner_shadow" /> </defs> ``` and then apply this color to the object you want to use for example: ``` lang=xml, name=connect definitions to actual objects <g id="Layer 1" <path d="M10,10 L90,10 L90,90 L10,90 z filter="url(#outline_outer_shadow)" /> <path d="M15,15 L85,15 L85,85 L15,85 z filter="url(#simple_inner_shadow)" /> </g> ``` - - - ## Implement presets in JSON NOTE: in this section the values between comparison signs `<type: value>` indicates what kind of input is expected or which one has default value. Because JSON uses `[` and `]` characters for arrays, this documentation uses `(` and `)` characters to indicate which values are optional. **Comments** A well structured declarative file needs comments too, but since JSON does not support comments and because I wanted to keep the file as *close to the standard* as I can, I come up with this solution:: ``` <string: literal block>: "#" ``` Because only those key-value pairs will be detected as comments which values are equal to `"#"`, it is allowed to add as many comment lines as wanted inside the same scope. Comments are recursively removed before the JSON file is processed. **Variables** A maintainable declaration needs variables as well, to make it even easier to change with as little effort as possible. One can create variables, assign values to them and use them later on in the JSON file. A variable can hold any kind of JSON data. The assignment is really simple: ``` <string: variable name>: <any: data> ``` Referring to a variable needs a `@` prefix: ``` <property>: "@<variable name>" ``` NOTE: At the moment there is no circular-reference checking! So it is quite easy to get a `RuntimeError: maximum recursion depth exceeded` in Python. **Colors and Gradients** To define a solid-color one can use a single dictionary: ``` <id>: { "color" : <string: hexadecimal, default=0> (, "opacity" : <float: 0-1, default=1> ) } ``` Gradients are list of color-dictionaries, but these colors also have a `stop` value: ``` <id>: [ { "color" : <string: hexadecimal, default=0> "stop" : <float: 0-1> (, "opacity" : <float: 0-1, default=1> ) }, { "color" : <string: hexadecimal, default=0> "stop" : <float: 0-1> (, "opacity" : <float: 0-1, default=1> ) } ] ``` NOTE: Each gradient stop value is required to be equal to or greater than the previous gradient stop's value. If a given gradient stop's value is not equal to or greater than all previous stop values, then the stop value is adjusted to be equal to the largest of all previous stop values. **Shadow filters** One can define inner and outer drop shadows as well: ``` <id>: [ { "type" : <string: inner|outer> (, "color" : <string: hexadecimal, default=#000000> ) (, "blur" : [ <float: 0-1, default=0> (, <float: 0-1, default=0>) ] ) (, "offset" : [ <float: 0-1> (, <float: 0-1, default=0>) ] ) (, "opacity" : <float: 0-1, default=1> ) (, "blend" : <string: normal|multiply|screen, default=norma> ) } ] ``` The first value of `blur`'s' or `offset`'s' list is responsible for the x-direction and the second value is for the y-direction. If only one value is provided in the list, the second value will be equal to the first one. NOTE: *Glow* effects are special cases of inner/outer shadows with zero offsets on each directions. NOTE: After I will use this system in real-life situations, it is possible, that I will refine it, or extend it with some new filters and settings, so it will be a constantly evolving solution for the designers. # Next Chapter: what shapes and dimensions are preferred to get the best vector -> raster icon?

Peter Varo commented

2014-02-22 16:18:45 +01:00

Changed status to: 'Open'

Peter Varo self-assigned this 2014-02-22 16:18:45 +01:00

Peter Varo commented

2014-02-22 16:18:45 +01:00

Added subscribers: @JonathanWilliamson, @brecht, @simonrepp, @PawelLyczkowski-1, @billrey, @ErickNyanduKabongo, @xrg, @lamoot, @petervaro

Tillmann Schütz commented

2014-02-24 09:37:44 +01:00

Added subscriber: @ionarn

Alexander Rulkens commented

2014-02-25 02:59:24 +01:00

Added subscriber: @rulkens

Warren Bahler commented

2014-02-25 21:19:43 +01:00

Added subscriber: @WarrenBahler

Diego Gangl commented

2014-03-09 22:59:36 +01:00

Added subscriber: @Januz

Paweł Łyczkowski commented

2014-04-27 20:03:07 +02:00

Since no one replied - I might, but keep in mind that I'm just a designer, and I don't hold any decisive power. Since Blender is open-source it is made by quite a fluid group of people (for instance the original designer of the icons no longer helps with Blender), so it has to use straightforward solutions - easy to grasp and maintain, hard to break. This proposition, while impressive, is the opposite of straightforward, so I don't think this is a good idea in this case.

Yann Masoch commented

2017-04-06 00:44:40 +02:00

Added subscriber: @Yann_M

Yann Masoch commented

2017-04-06 00:44:40 +02:00

What do you mean by Next Chapter: what shapes and dimensions are preferred to get the best vector -> raster icon?

A vector image has no degradation if you resize it (except for small dimensions). I am working a lot on Android UI and a good practice is to have an initial icon size of 864 x 864 pixels or bigger multiples such as 1728 x 1728. With a size of 864 x 864 an icon can be rasterized and downsized without loosing quality.

For examples:

final icon 24 x 24 | 864 / 36
final icon 32 x 32 | 864 / 27
final icon 72 x 72 | 864 / 12
final icon 96 x 96 | 864 / 9
etc.

What do you mean by **Next Chapter: what shapes and dimensions are preferred to get the best vector -> raster icon**? A vector image has no degradation if you resize it (except for small dimensions). I am working a lot on Android UI and a good practice is to have an initial icon size of 864 x 864 pixels or bigger multiples such as 1728 x 1728. With a size of 864 x 864 an icon can be rasterized and downsized without loosing quality. For examples: - final icon 24 x 24 | 864 / 36 - final icon 32 x 32 | 864 / 27 - final icon 72 x 72 | 864 / 12 - final icon 96 x 96 | 864 / 9 - etc.

Duarte Farrajota Ramos commented

2018-01-19 19:33:50 +01:00

Added subscriber: @DuarteRamos