For some reason we reverse the channel order when loading/saving a
PSD file. This doesn't seem to be necessary, and leads to a
reversed channel order across GIMP/Photoshop. Simply use the
normal channel order instead.
libopenexr was installed, but pkg-config was failing because of missing
dependency:
```
$ x86_64-w64-mingw32-pkg-config --modversion OpenEXR
Package IlmBase was not found in the pkg-config search path.
Perhaps you should add the directory containing `IlmBase.pc'
to the PKG_CONFIG_PATH environment variable
Package 'IlmBase', required by 'OpenEXR', not found
```
Looks like there may be a dependency bug in the openexr package in
Msys2. Anyway let's just add ilmbase and get this to be detected
correctly.
On 64-bit, all seems fine, but when building to 32-bit (at least Windows
32-bit), G_GUINT64_FORMAT is defined to "%llu" while time_t is a long
int. So it doesn't match and the compiler complains:
> warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'time_t' {aka 'long int'}
Let's cast to (guint64) to make sure the type always match.
Our installer use Msys2 packages when possible. And Msys2 repository
provides version 0.3.9, released on March 2, which contains our patches.
No need for them here anymore, no need to make custom builds.
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.
... 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.
… and additional source from python POTFILES.
These 2 fixes allow `make distcheck` to work fine.
You'll notice that I just commented the pygimp files out instead of just
deleting them. That's because there have been discussions and a patch
proposal lately about porting the pygimp API to Python 3/master. We are
not sure we want this yet for maintainability reason (and I was supposed
to be the one to wipe these files out!) but we'll see.
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.
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.
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
This is a new feature I implemented in the crossroad cross-compilation
tool. Msys2 repository has more packages and they are more up-to-date
compared to Fedora and Suse cross-built packages (the 2 other available
sources for pre-built Windows packages).
This allows to simplify a lot the dependency preparation for the Windows
CI, and speed things up.
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.
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.
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]
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]
`gegl` binary is being run for icon generations on gimp-2-10.
(cherry picked from commit 97549081fd)
Note: this commit is so far not needed on master as we don't call gegl
during build time unlike in gimp-2-10. But we could at some point.
Better to be thorough.
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 "trc" 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.
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.
json-c has 2 build systems (autotools and CMake) and it seems their
autotools broke with recent changes. I will report upstream. For the
time being, we may as well switch to CMake build.
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.
gimp_config_type_register() currently overrides GimpConfig::equal()
to only compare the properties of the most-derived type. However,
this prevents the properties of GimpOperationSettings from being
considered during comparison of operation-config objects. Instead,
don't override GimpConfig::equal(), and rely on
GIMP_CONFIG_PARAM_DONT_COMPARE to exclude specific base-class
properties from comparison.
Jehan