In gimp_filter_tool_real_config_notify(), make sure the incoming
pspec in not NULL before accessing it.
gimp_operation_tool_aux_input_notify() may emit "notify" on the
config object with a NULL pspec.
(cherry picked from commit 19c0d43c25)
When converting Brightness-Contrast to Levels, and Levels to
Curves, make sure to copy the common settings as well as the
operation-specific settings.
(cherry picked from commit 987447f18f)
In GimpCurveTool, don't reset the curve config manually, and rather
let GimpFilterTool reset it, only maintaining the active channel
(similarly to GimpLevelsTool), so that the common operation
settings are also reset.
Note that this also avoids keeping the channel curve types, which
should work correctly after last commit.
(cherry picked from commit 88689515ab)
In gimp_curve_config_copy(), make sure to copy the curve type
*before* the points, so that, when changing the type from FREE to
SMOOTH, we don't overwrite the copied points with interpolated
samples.
(cherry picked from commit 56693a8393)
It's minimal. I've not added CLang build or the Windows cross-builds
yet. Probably later. :-)
Only dependency changes from master are: GTK+2 instead of GTK+3.
Also GIMP is now built with --disable-python because even though Python
2 is still in Debian testing, apparently python-gtk2 is not packaged
anymore. So let's unfortunately drop this in our CI for simplicity sake.
This makes both master and gimp-2-10 CI now very similar, hence will
make it easier to fix one or the other.
In gimp_operation_config_sync_node(), when the operation has a
property of the config object's type, don't skip the other
properties. This makes sure to set the "linear" property of
GimpOperation{Curves,Levels} according to the config object. We'd
previously done it manually in GimpFilterTool, but the setting was
not applied when repeating the filter.
(cherry picked from commit 0096e563f6)
pygtk is being removed from distros, and this breaks our gimp-2-10 CI
build.
Removing it from the dependencies should make the build work
again, but means we lose building of the pygimp modules.
In GimpToolButton, don't let the group menu grab the keyboard focus
when showing it on hover. This avoids accidentally reassigning the
keyboard shortcut of the selected tool.
In file-psd, add support for exporting high bit-depth images. This
is currently limited to 16-bit images, since 32-bit images seem to
have a different structure (our loading code can successfully load
32-bit images exported by the plug-in, but not actual 32-bit PSD
files saved in Photoshop.) Higher bit-depth images are saved as
16-bit for now.
Note also that when saving a linear image with a built-in linear
profile the result is wrong (the image is exported with a linear-
TRC profile, but the data is perceptual), but this is a general
problem we have to fix, not restricted to the PSD plug-in.
(cherry picked from commit 9099f317bc)
Let's go with the logics "bottom layer is first", which is also the
logics in animated formats. Hence changing the layer order on loading
multi-page PDF.
(cherry picked from commit 809e79f37a)
As per commit ed7ea51fb7, reintroduce
the "Fade" functionality for filters, by incorporating it directly
into GimpFilterTool.
Add "mode" and "opacity" options to GimpOperationSettings, and add
a corresponding "Fade" expander to the GimpFilterTool dialog
allowing to control them.
Reintroduce the FADE layer-mode context, and use it to mark the
layer modes avaialable for fading.
Add a new gimp_drawable_apply_operation_with_config() function,
which takes an operation node together with a config object, and
applies the operation using the config options, including both the
operation-specific options, and the common GimpOperationSettings
options.
Use the function in gimp_gegl_procedure_execute(), so that
reapplying a filter takes the common operation settings used
originally into account.
Remove the common operation settings from GimpFilterOptions, and
instead, in GimpFilterTool, store these settings in the operation's
config object, which is now a GimpOperationSettings subclass, as
per last commit.
Add a new GimpOperationSettings class, to be used as a base class
for all operation-config types. The class provides options common
to all operations (namely, the clipping mode, input region, and
color options), which were previously stored in GimpFilterOptions,
and were therefore bound to the filter tool, instead of being
stored as part of the operation settings; as a result, these
options would have no effect when reapplying a filter, or when
restoring a preset.
The GimpOperationSettings options do not affect the operation
node, but rather the associated GimpDrawableFilter object. The
class provides a gimp_operation_settings_sync_drawable_filter()
function, which applies the options to the filter.
Modify all custom and auto-generated operation-config types to
derive from GimpOperationSettings, and modify the GimpConfig
functions of the former to account for the GimpOperationSettings
properties, using a set of protected functions provided by the
class.
... which determines if a node's operation-class has a specific
key, and can be used instead of gimp_gegl_node_get_key() when only
existence is important, to avoid compiler warnings.
Update the rest of the code to use the new function.
I don't reproduce these build warnings in my build but frogonia reported
them:
> warning: 'strcpy' accessing 1 byte at offsets 0 and [0, 2147483645] may overlap 1 byte at offset 0 [-Wrestrict]
And indeed the man of strcpy() clearly states that "The strings may not
overlap" (which is clearly not guaranted in current code as we don't
know the size of what's after the substring).
strncpy() might have done the trick as it doesn't say anything about
possible overlap or not, but let's just use memmove() instead where it
is clearly written that memory areas may overlap (note that bcopy() as
proposed by ankh would have also done the trick, but it is marked as
deprecated).
(cherry picked from commit 291af71e95)
… defaults to FALSE for PNG, TIFF.
The logics is that in most case, when alpha is 0, you don't expect color
to be retrieved and some people were bothered by this when erasing data
with eraser tool or selection deletion.
For the WIP image as well as for XCF format, we definitely want to keep
color data as there are workflows where you would want to erase/unerase
pixels subtly (selection also are not binary and should not be expected
to erase color data on layers with alpha channel). So we want to keep
the non-destructive behavior there.
Yet for export formats, going for "deleting what looks deleted" is a
valid approach, especially as it has been argued that experienced users
would know how to read and change the format options (and these
experienced users are likely the ones who may have valid reasons to want
pixels with full transparency to keep color values).
PNG and TIFF were the only 2 formats where I see such options, so
changing the default for these 2 plug-ins.
(cherry picked from commit 105c4efc8b for
the TIFF one and adapted to gimp-2-10 code for PNG)
