I know that the idea of black toilet paper is traumatizing nomis! ;-)
So here it is, using the CSS "!important" trick to override GTK+ CSS
recoloring code.
In order for the icon to be always visible, even on light background, I
am adding a path around the toilet paper shape (which this time will
be properly recolored by GTK+ with the foreground color, hence making
the icon clearly visible).
It should now be possible to fully export our symbolic icons from a
single central file.
My long-standing bug of librsvg#250 is still opened and unfixed, but it
turns out most issues I encountered are anyway also problems when
recoloring symbolic icons in GTK+ (like using strokes instead of
fills!). So let's just bypass all problems at once by accounting for
these issues in the design.
I tried to fix all the icons I could see which had issues regarding all
recoloring matters (using fill not stroke, change circle/ellipses to
paths, etc.) when looking at a blank canvas.
I'm sure I still miss a lot but that will do for now.
Sometimes even within symbolic icons, parts of the design must keep
fixed colors, when they are semantic. For instance this is the case for
the color-picker-(black|gray|white) icons or the gimp-default-colors.
The trick used by GTK+ to recolor is by supplying an additional CSS
style to icons which overrides inline CSS thanks to "! important"
keyword. Our own trick to circumvent this trick is to set "!important"
in inline CSS when one wishes not to have it overrided by the general
colors.
Right now I am doing the edit by hand with vim because Inkscape doesn't
seem to validate this keyword if I add it manually in its XML editor. So
what I did is add the "color-important" label on such object, and I will
later modify my SVG export tool to add !important on such object "fill"
values at export time.
The current recolorization code only recolors paths and rectangles. In
particular it leaves circles and ellipses as-is.
I opened the merge request gtk!214 for this issue. But in the meantime,
it is quite easy to change circles and ellipses into path with "object
to path" in Inkscape.
A second problem is that it only recolors fills, not strokes, as
previously stated. So I need to remove strokes from icons, or transform
them to paths.
For anyone wishing to help me fix icons, here is the trick: apparently
GTK+ would fill the paths with CSS colors, not stroke them. So when we
have icon drawing based on path-stroking, they don't end up as expected.
In Inkscape, just run "Stroke to Path" to transform a stroke design in a
fill design.
I am fixing "gimp-tool-cage", "document-revert", "gimp-image-reload",
"gimp-reset" and "view-refresh". More to follow as we discover them, I
guess.
Treat the gimp-core-pixbufs and gimp-icon-pixbufs resources like we
changed the cursor resources before, and clean out a lot of cruft from
icons/ (there is no need to generate stuff in all icon themes when we
include only one fallback icon from one theme).
With the symbolic-awareness of GTK+, vector icons are recolored (using
fg, success, warning and error colors). Unfortunately it was also
recoloring some rectangles with neither fill nor stroke, which were
using only to get appropriate icon size (these icons were therefore
displayed as just a square).
I made a quick pass in our icons to "fix" these. I expect I may have
missed some icons, or at the opposite, I may have broken other icons by
removing rectangles which should not have been removed. If you find any
such icon, please fix.
Also some icons do not look quite right just now. We will have to create
new guidelines on how to make symbolic icons and fix/redesign some, I
guess.
"gimp-detach" does not just use "gtk-convert" anymore and has its own
design. As for "gimp-attach", this is not used anywhere (yet), but it
could be soon as reverse action of gimp-detach. For instance, this icon
can be used for bug 791859 when we implement re-attaching overlay
dialogs.
These are simple on purpose since the smaller size they are displayed at
is 12 px (in overlay dialogs) so it needs to be simple shapes.
Note by Jehan: gimpicons.h and Makefile.am not updated yet. Waiting for
the color icons first.
The dashboard dockable shows the current GEGL cache and swap sizes,
and their recent history. It has options to control the update
rate and history duration of the data, and an option to warn (by
raising/blinking the dialog) when the swap size approaches its
limit.
It's not finished yet, but I have already added all the individual
Freedesktop and GTK+ icons. The goal will be to have all the Symbolic
icons in this one file so that in the future we can just extract
individual SVG files from object IDs.
This was the original plan but librsvg was just too buggy and would not
extract the proper viewbox for some icons. Fortunately it seems that the
bug reports I made are finally starting to be taken into account so I am
hoping for a usable librsvg soon and starts the work which should have
been done from the start.
These icons are requested by the System theme, which outputs warnings at
loading, so they are needed even when using vector icons otherwise.
Not sure why these are hardcoded. Maybe we should rather edit these out
from the gtkrc instead. But this will do for the time being.
This reverts commit 2226fb1dc8.
It doesn't make much difference right now, will work the same on
native builds and be broken on cross-builds.
I need to fix how invert-svg is built (broken on commit 84439a8),
so that it is a build executable again. Work in progress.
But since it makes no difference right now, let's just revert this
one already.
Jehan