Now, we can use whatever variable we want from 'config.h' with its
value, unlike the previous code which was hardcoded and did not
worked at all for variables with custom values like GIMP_RC_VERSION.
(Note: there are still work to do with Inno scripts)
It was caused by GTK finding host's canberra or others modules, which
is goappimage fault: https://github.com/probonopd/go-appimage/issues/332
This bug will remain if the distro have some uncommon module (e.g.
appmenu, colorreload), since we don't ship them.
In 9e8499bb, we forced image and drawable
previews to be 8 bit integer for compatibility.
However, this affects image previews when
in higher precisions, leading to banding
and other conversion issues.
Since the color space invasion, the original
problem should have less of an impact
as GIMP now handles conversions between
profiles much better. Therefore, we will
just grab the existing format for Grayscale
and RGB images, rather than forcing a
precision change to 8 bit.
As discussed on IRC these ops mostly duplicate other gegl ops and
have some shortcomings: range and gui-range, among other things,
are currently not supported. This causes some issues changing values
of parameters in GIMP, see e.g.
https://gitlab.gnome.org/GNOME/gegl/-/issues/403
Since they bring nothing new, and have issues, we will blacklist them
from the GEGL tools interface in GIMP, at least until they have
better support in GEGL.
After discussing with NikcDC and Wormnest on IRC, we agreed that maybe a
default of being sensitive when one or more drawables are selected seems
better, since the run() signature now has an array of drawables. So most
plug-in developers will consider the case when there are several
selected drawables as an obvious possible case.
And if someone really doesn't want to handle this case, they can always
set the sensitivity mask explicitly.
In particular, when setting a sensitivity mask but no image types, the
procedure was always sensitive.
Also make gimp_plug_in_procedure_get_sensitive() more robust.
Resolves#12854
Previously when loading filters, we used gimp_drawable_filter_apply ().
If there was also an active selection, it affected the recreation of the filter
and distorted the display.
This patch switches to using gimp_drawable_filter_apply_with_mask () so
that the filter's mask is always used instead, no matter if there is an active
selection or not.
gegl:pack replaced gegl:hstack almost 5 years ago, but the blacklist
for not showing it in our list of ops in Gegl tool was never updated.
Since Pack is also causing issues in GIMP, see #12890 and #12902,
let's update the blacklist add it there and remove the old gegl:hstack
that has been removed from GEGL.
Following e653535e
The meson-generated 'compile_commands.json' file added by 793c9588 shows an
assumption that we are building in-source, and assumptions are not welcome in
this general file, according to Jehan comment: !1021 (comment 1801018)
On export, when GIMP_EXPORT_CAN_HANDLE_LAYERS is not set
but GIMP_EXPORT_NEEDS_ALPHA is, we merge all layers in the image.
If there's a floating selection however, its attached layer is not included
in the exported image.
This patch converts the floating selection to a regular layer so that both
are included in the final export.
While we blocked rearranging a floating selection in the NDE GUI,
we did not add a check to prevent another filter from being moved
into it. Since a floating selection is considered a GimpLayer, applying
GimpDrawableFilter operations to it caused a crash. This patch adds
more safeguards to prevent this.
This reverts commit 490c8e7dc4.
Actually, I forgot to add 'GITLAB_CI' as an authorized MS Entra app on
Partner Center. So, I just done that and submission from our CI worked.
