I didn't expect this to generate so much interest :)
Jon A. Cruz wrote:
No, we don't. We'd only have to split things out if we let the system use it's file-based approach. That has many problems.
It also has one big advantage, namely you don't have to dig in the source code to discover which icon names you need to provide in your theme. The monolithic icons.svg file is also fairly unobvious to theme designers.
*However*, GTK+ supports all the calls needed for the application itself to be a source of named icons. We need to finish all the details of using it, but the main code is in Inkscape now.
I can't find the relevant GTK extension point. I think you are talking about gtk_icon_theme_add_builtin_icon(), but it's not documented whether the built-in icons sort in the lookup order after or before icons from the theme (we want them after theme icons).
That's probably the number one thing we have to do.
- determine which names in Inkscape are covered in Art Libre.
- list any issues of complicated names.
- determine which need to be added to Art Libre.
I used their names where it made sense, but I also changed some of them. Their wiki seems to be invitation-only - does anybody here have edit access?
Aaron Spike-2 wrote:
- Dogfood. People wanted to use our renderer for the icons as a visual
test and because other renderers weren't up to par.
We can use Inkscape's shell mode to render the icons at build time. It would be a matter of generating / writing a simple script.
- Startup time. IIRC startup times were shown to be significantly
faster loading icons from a single file.
I intend to render to PNG at build time, so it would be even faster than rendering all the icons at startup. An additional benefit is that if the icon is overridden in the user's icon theme, it will load from the icon cache, which is blazingly fast.
- Convenience for icon designers. Being able to look over a whole theme
and judge consistency and share gradients and such was a huge benefit. So I'm sure people would be happy if there was a workflow for generating the individuals from the composite.
I think that an automated export of SVG fragments + build-time PNG render is better than using the big file at runtime. We can distribute a script that will extract groups with IDs corresponding to the icon names and create discrete SVGs as well as PNG renders.
Probably I wasted some effort on manually extracting all the icons from icons.svg, but at least we'll have a naming reference for now. Inkscape could be used to extract the icons from icons.svg, but the --export-id option doesn't work with --export-plain-svg, and there is no --export-svg option (which would export Inkscape SVGs).
Regards, Krzysztof Kosiński