None whatsoever. :)

I suspect that most of the dark icons that are different from their light counterparts could be auto-ted and the differences are errors. So yeah, for any that aren't, the built script would simply avoid making an auto-generated version during compilation if there's already a handmade version in place. This would make it completely obvious which dark icons are handmade on purpose, since they would be the only dark monochrome icons in the source repo.

I have created montages of the different icons. The original files to the left, the generated to the right. (Hover the images to see the file path)

There are false positives:

Many have title bar buttons or panel buttons which should not be recolored:

Many have more subtle differences (look at the screws):

Many have big differences (which can maybe be avoided by improving the color substitution):

Sometimes the generated ones look better (debatable):

In some icons I don’t see whether the difference is intended (look at the border):

The script takes the output file of compare-dark-light.pl as argument. First you need to create the directory montages/.

Can you write a bash script which copies the icon files to icons-dark/ and substitutes the colors? Apparently you know how to do that, my bash skills are a bit worse.

Yeah, I was planning to. It would probably be helpful to do the cleanup first though.

I have to take some short notes here.

I have written a .sed script which we can use to convert icons/ files to icons-dark/ files. It does the same substitutions as my perl script above, but matches only in the stylesheet. That means, fixed colors will not be changed. That should fix things like this:

The script must be called with the -E option, because it uses new POSIX regexes.

$ sed -E -f swap_colors.sed -i file/to-change.svg

Open questions are:

• The icons in applets/ use #314045 as ColorScheme-ViewBackground, altough Icon_Workflow_Tips defines #232629. I think it should really be #232629, because that is the color which is actually used by the Breeze Dark theme. swap_colors.sed substitutes to #232629. The following picture illustrates what that means: (Auto-generated left, original right)
  
  I think we can do it how swap_colors.sed does it now, and get rid of icons-dark/applets/.
• Icon_Workflow_Tips defines #232629 for ColorScheme-Text, but many icons have #4d4d4d as ColorScheme-Text, for example those in icons/applets/, but also some in icons-dark/actions/. The latter is a mistake which will be fixed by auto-generating. The former is currently respected by swap_colors.sed, and auto-generated icons correspond to those in icons-dark. (I think the icons should actually use #232629, but than can be fixed independently.)

Next steps:

• Run the compare-dark-light.pl again with the new swap_colors.sed script, to be sure it does color swapping fine now.

By the way I looked through the 319 icons.

• Some icons actually need fixing in icons/.
• The emblem rating is blue in icons-dark/, because it links to another class. We can:
  • Leave rating in icons-dark/
  • Change the light version to be blue too
• (Probably) All mimetype icons in size 32px and 64px look significantly different in light and dark

Ah, that was an oversight on my behalf. I changed the rating icon to be black to fix a bug where it becomes invisible on a selected item. I probably forgot to change it to be white for the dark version. :/

Can anyone explain why rating-unrated and semi-starred-symbolic[-rtl] have 50% transparency, while rating has 100% opacity? That makes my compare script go wild, and I think it doesn’t look intended.

In T12855#224570, @davidhurka wrote:

Can anyone explain why rating-unrated and semi-starred-symbolic[-rtl] have 50% transparency, while rating has 100% opacity? That makes my compare script go wild, and I think it doesn’t look intended.

Any inconsistencies in the -symbolic icons are probably unintentional

Now we have less than 130 icons which are different in icons/ and icons-dark/, and less than 100 icons which we should keep as dark version. Maybe we can keep even less.

I have sorted them into two files.

@ngraham How’s your progress with the bash script? I’m currently trying to understand bash syntax. Maybe I can do it, if you don’t have done it already.

I haven't been working on it. There's an outstanding request to do this in a combination of CMake and Python, so it's cross-platform for Windows users of Breeze Icons too (see D27557#622879). Honestly I need to re-do the existing thing before that. But it's hard to gin up the motivation since I find working with CMake for anything more trivial than bumping a dependency version to be exceptionally unpleasant.

I could probably make the python script instead, but I'm in the same spot when it comes to writing CMake.