Alternatively, perhaps Inkscape itself can do most of this work via the Save as Optimized SVG functionality. We should investigate whether that's feasible, and if it is, maybe there's a way we can instruct users to configure Inkscape to do it automatically?

there are some things that perhaps cmake could do, like

• running the optimize scripts.
• perhaps do the dark version by replacing the values in the stylesheet

inserting the stylesheet, not really as you really need the stylesheet when you do the icon, to define what should use it and what shouldn't (no heuristic can guess it right)

also adjusting the icon to the pixel grid automatically is not really feasible (well, that's basically what the mindboggingly complex truetype hinting system does)

As far as I can tell, every single icon in the icons-dark folder is identical to the other ones with the exception of having the colors in the stylesheet changed. Auto-generating these in CMake seems quite feasible.

Inserting and applying styles can be done with icon template file with predefined swatches. Swatches (which are internally one-stop gradients) would be converted into style later with a script. Not trivial (i.e. not one line sed) to write due to indirect gradient use in inkscape, but also not really hard. Xml parser is the way to go. For extra newbie-friendly solution, "save as monochrome breeze svg" extension could be made.
From designer point of view use is really simple - in fill and stroke dock click "swatch" type and pick named color from a list.

Why breeze icons are "optimized"? As someone pointed out in another task, they are cached as bitmaps, so slightly more complicated XML is not a problem. Optimization creates real problem - sometimes icons after optimizations become hard to edit, so less people want to do modifications.

I don't trust optimizers enough to run them automatically unless it's scour. That's the only one I know of that doesn't seem to cause problems occasionally. Inkscape's Optimized SVG save option actually uses scour to do the optimization.

I'm somewhat open to the idea of only requiring optimization at build time for the sake of making it easier for newbies to contribute, but I prefer reading optimized SVGs in patches because that makes it easier for me to spot mistakes. The massive quantity of noise that Inkscape puts into SVGs, even plain SVGs, is staggering. Maybe we could have something that cleans the SVGs when submitted for a patch? If it won't work with Phabricator, it might work with GitLab.

In T11950#206330, @ngraham wrote:

As far as I can tell, every single icon in the icons-dark folder is identical to the other ones with the exception of having the colors in the stylesheet changed. Auto-generating these in CMake seems quite feasible.

There are a few that can't be auto-generated that way (gradients don't work with stylesheets), so we should have some logic to avoid overwriting files that already exist. Then we can eliminate all the icons that only need to have their stylesheet changed while keeping the option to do Breeze Dark specific icons.

Optimization creates real problem - sometimes icons after optimizations become hard to edit, so less people want to do modifications.

There are 2 main issues that Optimizers introduce (in order of severity):

• Gradients that don't get their properties from a referenced gradient can't be swapped with other gradients, unless you unset and reset the fill of the object you want to change the gradient for. This seems like a bug in Inkscape.
• Some optimizers combine paths with similar properties by default. This isn't a big deal if you know to go to Path → Break Apart in Inkscape, but obviously not everyone is going to know Inkscape or SVGs very well. It's hard to say how much a new contributor should be expected to know about SVGs or Inkscape.
  • Sometimes Break Apart causes objects to lose their properties and turn black. Usually not a big deal, it's very easy to fix, but not good for workflow.
  • I suppose we could just make sure we don't use any settings in the optimizer for combining paths.

For the Inkscape optimized svg gradient problem: https://gitlab.com/inkscape/inbox/issues/1121

Whoops, this Task went past me while I created breeze-icon-cleaner. What a pity!

I think with this tool, we can check the remaining four tasks of the TODO in the task description. Sounds optimistic? Well...:

• breeze-icon-cleaner repository has change-to-dark.pl, which converts icons from Breeze to Breeze-Dark. (Easy task...)
• It doesn’t “optimize” the icons, it creates new ones which are optimal. Below is an example, so you can judge yourself.
• It embeds the stylesheets. It doesn’t even require additional attention while painting the icon in Inkscape, it simply deduces the classes from the colors. Easier than what @mglb suggested...
• “adjust the text”? If code alignment is meant: see below.

<!DOCTYPE svg>
<svg version="1.1" viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg">
    <defs>
        <style type="text/css" id="current-color-scheme">
            .ColorScheme-NegativeText {
                color:#da4453;
            }
        </style>
    </defs>
    <path d="M 3 2 L 3 9 L 5 7 L 7 9 L 7 2 L 3 2 Z M 8 2 L 8 3 L 12 3 L 12 10 L 9 10 L 9 13 L 4 13 L 4 10 L 3 10 L 3 14 L 10 14 L 13 11 L 13 2 L 8 2 Z" class="ColorScheme-NegativeText" style="fill:currentColor; fill-opacity:1; stroke:none"/>
</svg>

Let me know what you think.

By the way: Nice that someone removed all that 24px icons and wrote a script to generate them. Thanks, @ngraham!

@davidhurka pretty impressive. I'll have to try it myself. If the dependencies are minimal and it's easy to use, it might be worth it to have the tool in the breeze icons repo.

Yes, looks very nice. Please feel free to work on this. My efforts were not very successful due to limited CMake knowledge and use of shell scripts instead of something more cross-platform like Python.

This is how my source file for find-location (D27983) looks in inkscape.

Would it be nice to post such screenshots in Revisions, instead of montage-breeze-dark images? Theese are a bit redundant with automated tools. The screenshot would make it easy to spot pixel-misalignments.

The montage-breeze output should stay, to see how the icon looks at original size. Or is another inkscape screenshot at original size (Key 1) sufficient?