Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
There was one case in Inkscape which we could not do: distributing objects
keeping even gaps between them. Until now, we could only distribute keeping even
distance between anchor points (top, left, bottom, right or center).
With these 2 additional distribute options, I believe that GIMP is able to do
all the Alignment and Distribution options available in Inkscape (not the
"Rearrange" or node features, neither the text align/distrib; I just mean the
common align/distribute on objects), and even a bit more thanks to the anchor
point system (e.g. in Inkscape, we can't left or right-align to a reference
object/image center, or we can't center to a reference left/right/bottom/top
border; but we can do it in GIMP).
The icons are hopefully temporary, until we can make better ones.
- Remove some forgotten lines related to 24x24 vector icons which were
removed a few days ago already.
- Don't install the 64x64 icons anymore as PNG when in the vector icon
case. Not sure why we ever did this, but it doesn't look useful.
- This should also fix the CI which was not looking for the tool
gtk-encode-symbolic-svg in vector icon install.
Some points to note:
- gimp-web and gimp-toilet-paper had some usage elsewhere so I also left
them in 2 of the more generic size files.
- I remove gimp-floppy altogether as it's used nowhere in any of our
code or data files.
There are some clear and obvious groups in the icons. For instance, the
Preferences icons are one of them. Looking up the code, we only use them
in 16px (in Preferences side menu) and 48px (in Preferences page
headers). Until now, we were storing in other unrelated size (22px) and
also the lists per-sizes were not consistent. Some icons were missing
here, other there.
With this new organization, the Preferences icons are listed in a single
file, ensuring usage and contents consistency. Also it allows to install
them only for the needed sizes (note that it is possible that they might
be needed in different size, for instance with custom themes; but we
can't just randomly distribute icons in all sizes; or to be more
accurate, this is exactly why we encourage rather the SVG/scalable
icons, so if some people explicitly go for raster icons, they also get
the drawbacks which come with).
Last note: it may be possible that some icons end up in different
"semantic" icon group. This is not a problem with this new organization
as my scripts handle duplicates gracefully.
Build-time tool, which basically just rasterize SVG images (it doesn't
do anything special like gtk-encode-symbolic-svg which creates special
PNG for GTK to recolor them).
It looks like I had this prepared since 2018 according to file header,
but I just never finished doing it! :P
Basically now PNG icons of the Color icon themes do not need anymore to
be committed in the repository. They will be generated from the SVG
icons.
Also adding a missing icon from the 16px list (the Playground icon for
Preferences dialog was needed in 16x16 as well, yet missing).
It may actually be meaningful to have redundant vector icons at specific
size, for instance when you want sligthly different designs (e.g. more
details at bigger size). But here looking at our 24x24 vector icons, it
doesn't look like it at all. It's mostly the exact same icons,
duplicated (with some forgotten).
Makes no sense here. So let's simply install the scalable/ icons for all
size, and that's it.
The lists are still exactly the same (except for one icon file whose
name the script fixed, which proves its usage/need even starting this
initial commit).
Now we also get more consistent tabbing than the manual one. Only
missing thing is that it was nice to separate some icons by categories
for easy reading. Maybe later.
… listing.
This way, both the Color and Symbolic icon themes, both on meson and
autotools build systems all share the exact same list of icons.
I think there are still improvements to be done on what we list and
chosen sizes and icon categories. But this step is about just getting on
the same state as we currently are, simply with shared listings. Once we
are there, we can go forward.
Now we get back (slowly) to something a bit saner, with a common list
shared on both icon themes. This way, we make sure we won't miss any
icon when we will add/remove/change any icon.
This is only for the meson build right now, but next step is to use the
same list in the autotools build as well. This will get maximum
consistency across build systems.
Alx Sa