Restore the behavior of gimp_gegl_apply_operation() prior to
11629fde66 when src_buffer is NULL:
keep the existing operation-node input, instead of using an empty
input. Unlike gimp_gegl_apply_cached_operation(),
gimp_gegl_apply_operation() doesn't have an explicit
connect_src_buffer parameter.
This fixes empty output when merging layers.
Rather than having the whole Win32 cross-build into the 'gimp' stage,
break the dependencies and GIMP-only builds in 2 stages.
Since apparently we need to keep the same structure for the native and
cross build (otherwise we don't get parallel builds; in other words, I
didn't find the possibility to set separate pipelines up), I move babl
and GEGL into the same 'dependencies' stage.
Finally I remove the -base rules extended into actual jobs, except for
`.gimp-base` (this is the only which makes sense as it is actually
common to the meson and autotools build).
We don't need to pull 5 commits of history. Only the HEAD of the
selected branch is needed.
Also define it globally rather than re-defining it in every job to the
same value.
First replace the "when: on_failure" rule by a "when: always". We indeed
always want to get log artifact so that we can study a build if
necessary (neither only on failure nor on success; really on all cases,
since even an apparently successful build may have issues we might want
to diagnose).
Also expire all artifacts at 1 week (it seems the default on GNOME's
Gitlab is 4 weeks; we don't need to keep these so long. Even a few days
might be enough actually).
As for the artifacts contents, keep the build dirs rather than the
install dirs. Build dirs allow to check configuration logs and other
kind of logs which are the most useful when diagnosing a failed build.
Now install dirs are also interesting. Maybe we should provide them
again at some point. We'll see. For now I comment them out.
Still keep the install dir for dependencies though, since it seems this
is how data are passed from one job to another.
Note that ideally we would like to provide different artifacts depending
on failure or success but apparently this is currently not possible.
See: https://gitlab.com/gitlab-org/gitlab/issues/18744
Also not sure why for GIMP, the CI was only keeping the build app/tests/
directory. We should really keep the whole dir.
In GimpFilterTool, don't provide a clipping option for layers with
no alpha channel, and always clip the result to the layer bounds,
since the extended regions of the result usually require alpha to
be meaningful.
Similarly to last commit, the ideal solution would be to
automatically add an alpha channel as necessary.
Alawys clip a floating selection to its base layer, if the layer
has no alpha channel. This avoids arbitrarily filling the extended
regions of the layer with, or compositing the floating selection
against, black color.
This is a temporary solution. Ideally, we'd automatically add an
alpha channel to the layer as necessary.
In gimp_gegl_apply_cached_operation(), add a boolean
connect_src_buffer parameter, which determines whether to connect
the source buffer to the operation-node's input, or to use its
existing input. In gimp_drawable_merge_filter(), pass FALSE for
connect_src_buffer, so that the existing filter-node input is used.
This produces an equivalent result, however, it avoids invalidating
the filter node, and dropping cached data as a result. In
operations that cache larger areas than the ROI, this avoids
reprocessing already-cached data when processing the rest of the
operation.
Additionally, in gimp_gegl_apply_cached_operation(), use an empty
input for the operation if src_buffer is NULL and
connect_src_buffer is TRUE; previously, we'd use the operation-
node's existing input when src_buffer was NULL. Furthermore, crop
the operation-node's input to the destination rect when crop_input
is TRUE, even if connect_src_buffer is FALSE.
They all had "class" as first argument (copied from gimpconfig-params.h)
and only worked accidentially because all functions they are used in
happen to have the right local "procedure" variable...
When the bounding box of a floating selection changes, update the
bounding box of the associated drawable, since floating selections
are no longer clipped to the drawable's bounds in general.
When attaching a floating selection to a layer, don't clip the
floating selection to the layer's boundary, and instead resize the
layer to include the entire floating selection when it's anchored.
As per the last commit, this can be prevented by locking the
layer's position.
When applying a filter to a layer whose position and size are
locked, avoid resizing the layer to the result size in ADJUST mode.
We do this by always returning GIMP_TRANSFORM_RESIZE_CLIP in
gimp_item_get_clip() when the position is locked, and properly
updating the drawable-filter's clip mode, and the filter-tool's UI,
when the position lock changes.
In GimpSourceCore, when "sample merged" is enabled, derive the
source pickable from the source drawable's image according to the
paint-core's show-all flag manually, instead of using
gimp_paint_core_get_image_pickable(), which uses the destination
image, and would therefore only work when the source and
destination images are the same.
In GimpSourceTool, override GimpPaintTool::paint_prepare() to set
the paint-core's show-all flag according to the source display,
rather than the destination display.
... which is called when starting to paint, before the tool's
paint-core is started, allowing the tool to configure the core.
Move the call to gimp_paint_core_set_show_all() to the default
implementation of paint_prepare().
Though the description of the POINTER type clearly tells of the new type
size, it was still refered as 32-bit only in this introductory text.
Let's fix this.
It was not necessary when I was only running the cross-build job. Not
sure why it is needed now. What do the parallel jobs share exactly in
this CI system? Anyway…
It looks like Arch does not have mingw64 cross-compilers in core package
repository. It does have some package in the user repository (AUR), but
I assume that such a repository cannot be deemed as safe.
Anyway I still tried, but apparently these AUR packages have to be built
and when I tried, I got this error:
> ERROR: Running makepkg as root is not allowed as it can cause
> permanent, catastrophic damage to your system.
Anyway it's all a big mess. Then I tried to move the cross-CI to Debian
testing, which is anyway our base compatibility system. Unfortunately I
encountered like what looked like some glibc++ macro problem on some
packages (most likely because the pre-built packages I use are Fedora
ones which likely uses a cross-compiler differently built from the
Debian one).
So in the end, for simplicity, I use a Fedora image, then I am sure to
get a good match between the system cross-compiler and the pre-built
dependencies.
Rodrigo Lledó