Reduce the pain of working on monochrome Breeze icons
Open, HighPublic


Breeze icons include inline stylesheets that allow them to change their color according to the user's chosen color scheme. This is a very cool feature, but imposes significant costs on icon creators. The full workflow is as follows:

  1. Create or edit 16px Breeze light theme version of icon in Inkscape
  2. Create or edit 22px version of that icon
  3. Create a 24px version by expanding the margins by one pixel on all sides
  4. optimize the SVG files by running one of the hacked-together scripts here: in a shell for loop that you likewise have to do yourself
  5. Fix the attributes in the path tags of all icons using the hacked-together scripts here in a shell for loop that you likewise have to do yourself
  6. Embed the stylesheet into all three icons by hand (or fix them by hand if editing an existing icon, because Inkscape has mangled them)
  7. Manually copy all of the edited icons into the appropriate location in the icons-dark tree to make Breeze dark versions. Then run another shell command in a for loop to convert the colors in the just-copied versions to the appropriate Breeze Dark versions

The difficulty of accomplishing steps 3-7 mean that only two or three people work on monochrome Breeze icons, and even for them, altering many monochrome icons at once is incredibly painful and awful.

We should fix this problem by having the build system do all the work for us!

After creating the Breeze light version of a monochrome icon in Inkscape, nothing further should be required of you as an icon creator. CMake should:

  • Auto-generate the 24px versions: D27557
  • Auto-generate Breeze dark versions from the light versions with appropriate colors
  • optimize the icons
  • embed the stylesheets
  • adjust the text within each icon to make sure that everything's wired up properly
ngraham created this task.Oct 31 2019, 4:30 PM
ngraham triaged this task as High priority.

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?

mart added a comment.Oct 31 2019, 4:49 PM

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.

ngraham added a subscriber: Frameworks.
mglb added a subscriber: mglb.Oct 31 2019, 11:23 PM

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.

ndavis added a comment.EditedNov 1 2019, 1:22 AM

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.

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 PathBreak 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:

ngraham updated the task description. (Show Details)Feb 21 2020, 10:01 PM
ngraham updated the task description. (Show Details)Feb 23 2020, 4:46 PM

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, 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="">
        <style type="text/css" id="current-color-scheme">
            .ColorScheme-NegativeText {
    <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"/>

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?