When building (at least on 32-bit), fixes this warning:
> app/widgets/gimpdashboard.c:3840:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Unsigned long long is specified in the C99 standard to be at least
64-bit. So it's normal that the compiler complains, as a cast from
unsigned long long to a pointer has chances to go very wrong.
Yet gimp_backtrace_get_frame_address() actually returns a guintptr which
is type-compatible with gpointer so let's not give the compiler false
information and just use this type. Then cast it to unsigned long long
just for printing to dashboard log.
(cherry picked from commit 8caef4ea0b)
... when rulers and scrollbars are hidden
In gimp_display_shell_fill(), make sure a size-allocate always
happens for the canvas, even when the rulers and scrollbars are
hidden, so that the pending size_allocate_center_image is handled,
and doesn't block canvas drawing.
(cherry picked from commit 4e560f2ff0)
I am comparing absolute value of 2 double computation results. Might as
well just use fabs() instead of truncating both values to int.
Fixes the following:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
(cherry picked from commit f6dd30f3a8)
Fixes the following bug:
> warning: absolute value function ‘abs’ given an argument of type
> ‘glong’ {aka ‘long int’} but has parameter of type ‘int’ which may
> cause truncation of value [-Wabsolute-value]
(cherry picked from commit fddaa77218)
Fixes:
> warning: using integer absolute value function ‘abs’ when argument is of floating point type ‘double’ [-Wabsolute-value]
(cherry picked from commit b71754f2a7)
1 > warning: "_WIN32_WINNT" redefined
2 > pointer targets in passing argument 2 of 'send' differ in signedness
3 > passing argument 4 of 'setsockopt' from incompatible pointer type
For the signedness/type issues, I just casted to (void *) which was the
expected type for these parameter on the Linux API anyway. As for
Windows API (which was expecting char* for these various API), the
compiler just does the cast itself from void* without complaining
anymore.
(cherry picked from commit c280cb9da7)
On Windows, accept() wants an int for addrlen but on Linux, it wants a
socklen_t which is an unsigned int. So we can't just switch to gint as
proposed in !232 (if we do so, the signedness warning now happens on the
Linux build instead of the Windows one).
Fortunately it looks like socklen_t is actually typedef-ed to int in
Windows headers. So let's just use this type, which is much more proper
anyway as this variable is only used in functions which want this type
on Linux.
Fixes:
> warning: pointer targets in passing argument 3 of 'accept' differ in signedness
(cherry picked from commit e854de73ee)
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.
