Some jobs were using the Debian image from Docker Hub registry:
- meson-health
- clang-format
- cppcheck
- sources-debian
- dev-docs
- dist-appimage-weekly
The reason was that we don't need a bigger image suited for builds
($CI_REGISTRY_IMAGE:build-debian-${DEB_VERSION}-${RUNNER}), but
it relied entirely on luck. If we push too much commits in a day, it
could surpass the Docker Hub limit. So, let's use our own image always.
This fixes the following warning when compiling with CLang:
> libgimpwidgets/gimppropwidgets.c:3961:11: warning: variable 'unit_type' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> 3961 | if (pspec_unit && GIMP_IS_PARAM_SPEC_UNIT (pspec_unit))
If a unit property name is set, it must be a valid unit property. Let's
check, output a CRITICAL and return NULL otherwise.
This macro will generate a #warning message when we'll move on to 3.99
series (which means we will be on our way to GIMP 4). And it will become
an #error message on 4.0.0, hence preventing us from releasing unless we
actually resolve all these warnings.
Resolution may mean actually breaking the API/ABI, or just deciding that
it's not a good idea in the end, or finding another solution. But
something will have to be decided.
Please everyone use this macro when you discover issues where it looks
like we could improve the API (in a breaking way) so that we don't
forget when approaching GIMP 4 (pushing further the improvement).
Updating the 2 place where I was already using a GIMP_CHECK_VERSION()
with #warning, and adding a new usage in the compose plug-in, per
discussion in MR !2424.
Though I can't reproduce on Linux, the performance log seems to show we
spend too much time inside filters_actions_update(). Instead of creating
nodes at each update, let's just store the information about which
filter action has pad, since this should not change within the timespan
of a given session.
Runners do not remember the MSYS2 repo cache between jobs since
they are not relying on any Docker caching.
The problem is that GIMP could link to different lib versions than
babl and GEGL, but that is the way local shell executors work anyway.
The strings used in decompose.c's "decompose-type" do not match
the values of compose_type for YCbCr values. This means that when
using non-interactive Recompose, there's no match and the Recompose
fails. We'll need to wait until the next API break to fix the strings.
For now, we will do additional checks if the normal compose_type check
fails and also compare the four YCbCr types from Decompose.
The button for opening the edit panel for editing a brush / gradient /
pressure curves looks misaligned because it is added to the end of the
horizontal box and its icon is aligned to the end of the button instead
of its center.
This adds puts the text entry and the edit button into the same
horizontal box and fixes the image alignment.
In the case the "create-custom-widget" signal is not emitted (typically when
using the print portal), it is necessary to open a second dialog to fine-tune
the print settings.
Remove most of the per-action special-casing. This won't scale, and in
fact it already doesn't work well with all generated actions from GEGL
operations. Considering that any third-party operation will generate an
action too, this just can't work.
Instead we know that:
- Filters on group, vector and link layers must always be run
non-destructively.
- Non-interactive filters are always run destructively and therefore
cannot be run on group, vector or link layers.
- GEGL graph as well, unless a specific environment is set.
- All operations with auxiliary inputs cannot be run non-destructively
(yet) either and therefore must also be deactivated on these layer
types.
A few more actions are still special-cased (in particular regarding
being used on grayscale drawable or on formats with an alpha channel),
though it would be nice if we could generalize these somehow eventually
too.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
Previous implementation was always keeping ratio. If the width/height
argument were of a different aspect, librsvg simply fits the image with
original aspect within the box. Now we will appropriately scale
differently on both dimensions to have the image fill the whole box.
Note that this doesn't work with librsvg before 2.46.0 (not that it's
not possible, just that I haven't looked at how it should be implemented
there (which would be a different implementation anyway since there is
no cairo step).
Finally I add a build warning for when we'll prepare for GIMP 4, as the
pixel density arg needs to be split in 2 (each dimension can have its
own PPI), even though this is not really needed right now.
Note that it's not actually tested with an old librsvg, but only forcing
this code path with a new librsvg and fixing the compilation
errors/warnings which are outputted.
