If running for instance in a cross-compilation, I need to make clearer
the fact we are looking for a native GEGL and also that we are looking
for the executable (used during the build), not the library. This is a
different test as the one for the library with PKG_CHECK_MODULES (which
looks for the target platform's library).
Move the button-highlight update to its own function, and call it
when the active image changes, as well as when its floating
selection changes.
Call the floating-selection-changed signal handler when the active
image changes, so that we correctly update its row's attributes.
We disallow creating a new layer from a floating selection when its
associated drawable is a channel, so there's no point in
highlighting the "new layer" button in this case. Note that the
"layers-new" action remains sensitive, showing an error message if
activated. Not sure if it's a good thing or not, but whatever.
... when there's a floating selection
Layer-dialog interaction is restricted while the image has a
floating selection, which often causes confusion. Highlight the
three layers-dialog buttons that "finalize" a floating selection --
the "new layer" button, the "anchor layer" button, and the "delete
layer" button -- to indicate that these buttons are used to finish
the paste operation. The "new" and "anchor" buttons use a green
highlight color, while the "delete" button uses a red highlight
color.
In gimp_plug_in_open(), use gimp_spawn_set_cloexec() to prevent the
parent's end of the read/write pipes from being inherited by the
spawned plug-in, instead of passing the corresponding file
descriptors to the plug-in as command-line arguments, and having
gimp_main() close them.
Adding new command-line arguments to plug-ins is problematic, since
their ability to handle them depends on their protocol version,
which is only communicated after the plug-in is spawned.
Regardless, this is much simpler.
Reap the child *after* we're done reading its output, so that we
can disable ptracing after reading, but before reaping. This
avoids a window during which the child is gone, but ptracing using
its PID is still allowed.
Clear the ptrace permission given to the child after it terminates,
so that a future process that happens to have the same PID the
child had can't ptrace us.
In gimp_plug_in_open(), use gimp_spawn_async(), added in the
previous commit, instead of g_spawn_async(). See the previous
commit for the rationale.
Since gimp_spawn_async() doesn't provide a mechanism to perform any
cleanup in the child before exec()ing, move the closing of the
parent's end of the read/write pipes from the app to the plug-in's
gimp_main(), passing the relevant file descriptors to the plug-in
through argv.
gimp_spawn_async() is similar to, but more limited than,
g_spawn_sync(). Unlike the latter, gimp_spawn_async() uses
vfork(), instead of fork(), when possible.
On Linux, a process that uses large amounts of memory (as GIMP may)
can hang during a fork() if overcommitting is enabled, and there's
not enough memroy. Using vfork() avoids that, since it doesn't
duplicate the parent's address space.
On Linux, when /proc/sys/kernel/yama/ptrace_scope is 1, a process
may only ptrace its descendants by default, which prevents the GDB
process spawned by gimp_stack_trace_print() from attaching to, and
producing a backtrace for, the calling process.
Use prctl() with PR_SET_PTRACER, when available, in the parent
process, to allow the child process to ptrace it.
Rather than just assuming all non-gray images are RGB, do a bit more
robust check and reject unknown formats. Indeed even though I see we
took care of YUV, e-YCC and CMYK images above (and normally either
converted them to RGB or already exited with an error), I can see that
the OpenJPEG library could still return OPJ_CLRSPC_UNKNOWN or
OPJ_CLRSPC_UNSPECIFIED. Let's be thorough and not assume we got a SRGB
here.
Also add the alpha-variant tests inside their parent image type
respective test. This should not change anything by any logics, but
let's not leave anything for chance to strike us.
Finally minor coding style fixes:
- Add a space before "if|for" and parenthese.
- Remove some spaces after parentheses.
- Get rid of 2 trailing whitespaces.
- Align function call parameters, declarations, assignments…
Made plug-in support the RGB and grayscale with alpha.
Comment by Jehan: this makes the original branch work finally usable on
some JPEG 2000 images. Support of the format is not complete yet though
but at least the port to OpenJPEG is now in usable test.
In case of error in gimp_prop_eval_parse_reference(), we were obviously
freeing the string which had just been allocated by g_strdup(), not the
pointer to this string.
Thanks to Massimo for raising this issue.
gegl:recursive-transform applies a transformation recursively to
an image. The custom GUI allows controlling the transformation
matrix using a transform-grid controller, added in the previous
commit.
... which allows ops to create a transform-grid widget, similar to
the unified-transform tool, which can be used to control a
transformation matrix.
Implement the transform-grid controller in GimpFilterTool.
Since the entry behaves differently based on whether the user
provided an explicit input or not, it makes sense to have a button
for clearing the entry.
The bug is very hard to reproduce, probably because it requires specific
timing conditions but this looks like this commit would prevent it.
Apparently the signal handler gimp_container_view_name_changed() may
have been run while the container view (set as user data) was most
likely already finalized, hence leaving an invalid dangling pointer.
Let's just make sure we disconnect this handler (and another) when we
finalize the container view and its private data.
In a previous commit, I bumped it for Windows only, where major bugs had
been fixed in recent fontconfig. Yet as Mitch notes, Debian testing has
Fontconfig 2.12.6, so we can simply use the same requirement on all
platforms. No need to make our configuration script over-complicated
with per-platform requirements here.
Jehan