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.
- 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.
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.
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.
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).
A -quick done- first step towards the addition of a smart selection tool.
Require the gegl:paint-select workshop operation.
Still LOT of work to do (wip):
- fluctuations removal (GEGL side)
- multilevels pyramid approach + banded graphcut for instant result on large
image (GEGL ? GIMP ?)
- Gaussian Mixtures for color models (GEGL side)
- drawable offsets (GIMP side)
- undo / redo (GIMP side)
- scribbles edition mode (GIMP side)
- dedicated icons
- ...
So it turns out there are still a few bugs in librsvg position/size
computation. One of them is described in my comments:
https://gitlab.gnome.org/GNOME/librsvg/-/issues/250#note_900325
To work around them, I had to increase stroke width of a SVG <circle> to
be over 0.5px.
See commit 1e5cf10585.
I am reorganizing again a bit the global file with all icons to
experiment a bit again with icon extraction using librsvg (let's see how
the library evolve since last time I tried, a few years ago!).
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
This is a quick and dirty fix to just deal with this specific issue, but
looking at meson rules for icons, it looks like I will need to do a
proper and very detailed review of this part of the build system.
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
Allow setting the type of GimpCurve control-points to either SMOOTH
or CORNER. Smooth points produce a smooth curve, while corner
points produce a sharp curve (previously, all points were smooth).
In GimpCureView, display corner points using a diamond shape,
instead of a circle.
In the Curves tool, allow changing the curve's point types.
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
We don't need to commit PNG symbolic icons as `gtk-encode-symbolic-svg`
is perfectly able to generate them from the SVG.
Moreover its man says that it makes "specially prepared png files",
whatever that means. So I don't think we should just rename our
self-exported PNG files as '*-symbolic.symbolic.png'. It is better to
generate them with this tool.
Note that I am now splitting icon-list.mk into 2 files. This is only a
temporary stepback, as I am actually going to merge the 2 icon themes
into one very soon, and hopefully we should be able to generate the list
to ensure we don't miss an icon.
Anyway the icon lists had already diverged earlier, even though it was
only all still in a single file.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06f
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
Anders Jonsson