One way to store symbols and icons, is to store them as more like a font.
See Apple’s new SF Symbols, which has 1500 symbols, each with different weights, and they can even be combined, filled or not, etc:
https://developer.apple.com/design/human-interface-guidelines/sf-symbols/overview/
IMO, this is quite a nice, flexible system that can grow more than our curren icon sheet system.
Interesting indeed, seems to me though that this would not allow alternative icons from the user, like it was currently planned.
Hey - looks like SF system allows for custom symbols.
I don’t know anything about the way the icons are stored by Apple, but in general it’s way to go - super easy to expand. The only thing that’s needed is a good naming convention/system. Besides glyphs storage system of course 
Deleted content: That’s why individual files are the way to go.
On the contrary - if icons are stored as a font, you could just swap out the font.
Well, actually swapping out icon sets are an argument against individual files. It’s a lot harder to manage then.
I don’t know much about this, but if the icons are treated as a font or similar wouldn’t they be limited to be monochromatic?
If so the whole point to have them configurable by the theme wouldn’t make much sense any more.
If it’s more convenient for icon designers to have an individual .svg file for each icon that can be done. I would think that makes some types of global edits harder, but I guess the file being so slow to edit is worse.
Encoding them as a font does not seem simple or really helpful to me. They are monochrome only and I don’t know that reliable automatic conversion from SVG to fonts exists. If icon sets need to be a single file for distribution it can a zip file or encoded as a single file in some other way.
Splitting the icons would require changes to the Blender code which are probably not that hard, but it also requires splitting up the SVG file. I don’t know if there is an easy way to automate the latter.
What about the icons I marked in red in my previous post @jendrzych ?
Were they supposed to be used and there was an error at some point or did they remain in the sheet for hypothetical future uses?
I also forgot about this one:
It’s used in the outliner filter and in the properties editor as speaker_data, but it’s not consistent with the outliner’s tree icon.
Also, I guess having 1 icon per file makes customization more flexible:
If you want to change a few icons only, you just have to change those and don’t have to care about the others.
Re-organizing is a huge feat, as you have to change the icons_ui.h file to move each change/swap to the the right row/column, cleanup and rename the XML code of the SVG file, delete and recompile all the dat icons. If you are not careful with the H file, then things will break quickly.
RE font
RE icons reorganisation
I would make the original svg file with any icon organization as convenient to the designer, but with the proper names of each icon (svg group). Then, the icons are exported to individual png files, the file names are automatically taken from the group name. Call the icon by file name.
Using a font for the icons would be great, but it might be a couple years away.
As you mentioned current fonts don’t support some of the features we need, like differing opacity. And I personally wouldn’t consider it until it can also do color. And all that means we are waiting for FreeType, the text rendering engine we use, to support OpenType-SVG. Once they do it will be fairly easy to convert. Then we’ll have everything we have now, but vector scalable and no real restriction on how many we can have.
Well, that’s true. What I rather mean is “transport” as seen in audio related programs. They don’t have jump-to-keyframe buttons obviously. But I can think of another rationale: Start, end and current frame are properties of the scene, whereas keyframes are object properties (for the most part).
There’s no issue with colors for a font-like icon system. In Blender, the icon colors are added in code via themes. The actual glyphs themselves have no colors - they are just vector shapes.
I guess that’s the issue with fonts. People will want to do more than choosing a tint for entire icons, they will want to have several colors in each icons.
Until you consider edits like mine, which you’re just completely discounting there.
As far as splitting the SVG into individual files goes,
As someone who has personally done such an edit, and been over every icon, having them in a single file is much less tedious than having all the icons in individual files aswell. Unless there is some convenient way to split the SVG, and the master SVG handed around is pre-split, it’d heavily discourage creating custom icon sets.
Yes, I’d hate to move to anything that causes any constraint on what we can do, which is why I am waiting for better adoption of OpenType-SVG by FreeType. They had this as a possible Summer of Code project this year so hopefully it won’t be too long. Might be something for Blender 3.0…
It appears that OpenType-SVG is a FreeType Google Summer of Code project. Look at the June 13, 2019 section of https://lists.nongnu.org/archive/html/freetype-devel/2019-06/index.html
That is awesome news. The original spec was very broad and detailed and hard to implement, so full adoption has been slow with various things, like Firefox and Internet Exploder, doing different subsets of features. But recently everyone has agreed on a minimal spec for a limited profile of features which has helped push people along. We only need that minimal spec. I don’t think anyone really needs every feature of SVG, like animation, in their fonts. LOL
Even if the OpenType-SVG supports all the features we need, I still see no reason to use the font for icons. What are the advantages of a font over a set of SVG files? Why do we need an extra step to convert SVG to font?
For example, now I can easily replace the toolbar icon files, but I can’t create these files because of their strange format. The same will happen with fonts, 99% of users who want to use custom icons are not able to create a font file.
Although, I don’t see the point to use even SVG, regular PNG files work fine for application icons.
What’s more, users are asking for the ability to use custom icons, instead of implementing this feature, you are discussing the implementation of an unnecessary feature which will only complicate this. That’s not looking good.
Good question, as that might not be immediately obvious.
Right now the icons themselves are defined as vector (infinitely scalable) images in a SVG file. But they are not used that way. Instead there is a process where we use Inkscape to convert that SVG into two bitmap images, one for 14x14 icons for when the interface is at 1x scale, and another larger one for 28x28 icons for 2x scale. And those become little “dat” files in the file system.
So we start with something perfectly crisp and perfectly scalable and end up using fixed-size bitmaps. Set UI scale to 3 and immediately see the limitations of that.
Ideally we could we have an engine inside Blender that could take a vector image and directly rasterize any size needed from that. We could have infinitely scalable icons that always look their best and skip all that exporting business.
We have such an engine. Blender prints out text using a library called FreeType. It directly uses vector files (fonts) and rasterizes whatever size text we ask of it. Works fast and perfectly. But only does so for the simple monochrome shapes that define most fonts today.
But fairly recently emojis were added to Unicode. At that point people then needed to add color to fonts and that resulted in a few ways to do so with some standards accepted lately.
So with OpenType-SVG implemented in FreeType we’ll be able to have icons that can look good at absolutely any size. In a compact format that only stores outlines, paths, gradients, shapes with opacity, etc. And a font file could contain thousands of icons without concerns about space or vram. And anyone could change the icons by replacing the single file.