The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
The bug is in fact in GTK. "image-missing" is supposed to never missing since
GTK embeds an icon as GResource. But it turns out that the code is buggy. So if
an icon is missing from GIMP theme, then system theme, then "icon-missing" icon
as well, GIMP crashes.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/3526
As a workaround for now, let's at least add our own "image-missing", at least in
our main themes (Color and Symbolic, not Legacy). This will make GIMP not
crashing at least by default when another icon is missing.
Of course a crash could still happen if one use Legacy or a third-party theme
and if their system theme doesn't contain "image-missing" as well, until GTK is
fixed.
We already search for a compatible Python version in the root meson file, no
need to look up Python 3 again in the PATH, each time we run an external Python
script in the build.
This should hopefully fix#9687.
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.
Fixes:
> make[3]: *** No rule to make target '64/dialog-question.png', needed
> by 'gimp-core-pixbufs.gresource.xml'. Stop.
It looks like a bug in autotools on Windows because there is no reason
why it would fail. The missing PNG should be caught by the '64/%.png'
rule. Anyway after testing, it fixes the gimp-win(32|64)-native CI jobs.
Our Symbolic icon theme comes from the art-libre theme now archived by
the GNOME design team. It had various authors, including originally
Jakub Steiner and Barbara Muraus, then jEsuSdA, Klaus Staedtler,
Alexandre Prokoudine and Aryeom Han. Various other people tweaked the
icons and may have contributed. See the git log for details.
The Color icon theme is more of an original work by Klaus Staedtler, as
I understand it, with some additional icons by Alexandre Prokoudine,
Aryeom Han and other contributors. See the git log for details.
This makes licensing clearer for these specific subsets of the project.
Though the Color and Symbolic icon themes will have a different build
process and naming scheme for their icons, the base list is meant to be
the same by maintenance principle. So I am moving out the lists to the
icons/ directory's meson file.
Bumping meson requirement to 0.53.0 because I need to ability to use a
variable as dictionary key (not only string literals), which appeared in
this version. Meson 0.53.0 was released 2020-01-07 and seem to be used
in any stable distribution released since 2020. In any case, it seems
widespread enough to bump it now for our dev branch.
Ok that was a bit of a mess with the 4 build cases (combinations of
meson, autotools, vector and raster icons). I *think* this is now OK.
Basically we still need to build the colorsvg2png tool even when
installing vector icons, just for the purpose of the 2 icons
dialog-question and gimp-wilber-eek which we compile into GLib resources
from PNG images.
Also it looks like I completely forgot to add the subdir meson.build in
icons/Color/.
Even though we only generate makefiles, we actually want to make meson
aware of the list change because it continues using the file list from
the previous configuration. We do this by "touching" the meson.build
files, i.e. editing their access time.
Also rebuild the icon-list as there are small changes forgotten.
Now the source images are in the build dirs.
Also:
- clean the EXTRA_DIST contents on autotools;
- add dependencies rules in meson gresources to make sure icons are
built before resource build;
- finally remove a duplicate build rule in Color Makefile.
Bad usage of `find`. I didn't pay attention that I removed icons from
the Legacy icon theme which is frozen. Obviously the previous commit was
only expecting to touch Color and Symbolic icon themes.
- 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.
Just so that someone who happens to look in there is not tempted to
modify these files directly and get some instructions.
The comment is inspired from other similarly generated Makefile.am (i.e.
in plug-ins/commons/).
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.
I realize that this module is available since meson 0.53.0 though our
current requirement is meson 0.50.0.
Note sure why meson was not popping any warning (normally it does when
we use a feature younger than the minimum requirement; but maybe this
doesn't work for modules).
Anyway this does the same thing without the 'fs' module, and maybe even
better (we know which icons should be converted or used from source, no
need to add any test logics here).
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.
The whole logics of creating specially prepared PNG images for vector
icons (with gtk-encode-symbolic-svg) was absent. This option was
basically completely broken, yet we now know that we need the ability to
install PNG alternatives for the icons (see #6821).
This is a continuation of previous commit which is straightening a bit
our whole icon theme builds. Note though that more needs to be done
because I definitely still see room for more mess and far too much
duplication.
Some icons were missing on one side or another side, though mostly on
the meson build. Also the option -Dvec-icons=false was basically
completely broken and clearly untested, most likely ever since the
original meson build contribution.
This commit doesn't even completely fix the non-vector icon rule,
because even the file names are wrong, and the bitmap icons are not even
constructed from their vector counterpart! I am going to fix this in the
next commit.
We should really get back to a single shared list as we have in
gimp-2-10.
Also just keeping the "no SVG icons" option feels wrong to me, yet it
turns out librsvg is quite a problem because of Rust, so recent versions
are just not available on many platforms (see #6821). This is what
blocked me so far to remove this whole listing of PNG variants for our
vector icon themes. Otherwise they would be gone by now.
I really wonder as well about all these size categories. Not that they
are not needed when in PNG format, but because it feels like nobody has
really taken the time to list which icons are needed in which size for
years. We really need to do some cleaning in this area.
Will tweak them again later. It's just for a first version so that there
are no missing icons.
Unlike the Symbolic icons, the lock design is custom.
CC by-sa International 4.0.
To better explain the lock icons, have specific icons instead of reusing
other icons. We also tried to programmatically add the simple lock icon
over the other icons, but we only got ugly render. Better have
custom-made icons.
The gimp-lock icon is the Adwaita system-lock-screen icon, by Jakub
Steiner, simply renamed. Therefore its license is GNU LGPL v3 or
Creative Commons Attribution-Share Alike 3.0.
The other icons are derived from a mix of this same icon and other icons
in our existing set and have the same license too.
The issue is that on X11, the window manager draws the title bar hence
uses the window-close button from the system theme, though on Wayland,
GTK draws its own decorations. Since we provide a window-close, we end
up with a disparity between this button and the minimize/maximize
buttons.
For now, let's just get rid of the window-close icon as an easy
solution, thus GIMP will always use the window-close icon from system
theme.
Maybe we can restore our own window-close icon later, but we should make
sure to at least have also window-maximize and window-minimize icons so
that the 3 buttons next to each others won't look too mismatched. And
probably we should also have smaller-size design because it doesn't look
so nice when huge (though it might simply have been the size mismatch
which gave this feeling).
Actually most of the build code was already there but the initial meson
contributor commented the Legacy icon theme out. Not sure why.
I only had to fix a few icon names, which changed into Freedesktop
standard names after commit 1e5cf10585. Other than this, existing meson
build rules seem to work fine AFAICS.
Jehan