These procedures freeze/thaw the corresponding containers of the
image, allowing plug-ins that perform many changes affecting any of
these containers to suppress updates to the corresponding dialogs,
significantly improving performance.
We were only able to translate selections and layers (bot not channels
and paths) via the PDB, this new procedure fixes that. Deprecation of
old API and some more transform consistency to follow...
Don't unconditionally overwrite all the proc's description, author
etc. Instead, try to preserve them and append the "Deprecated" notes
to the help texts and generated comments.
Only affects one procedure because we killed the meta info of all
other deprecated procs so far, but now we don't have to do that any
longer.
Add new PDB group "drawable_edit" which has all procedures from the
"edit" group which are not cut/copy/paste.
The new group's procedures don't have opacity, paint_mode
etc. arguments but take them from the context instead. Unlike the old
gimp-edit-fill, gimp-drawable-edit-fill now uses the context's opacity
and paint_mode.
The new gimp-drawable-edit-gradient-fill procedure uses even more
context properties which are also newly added with this commit
(gradient_color_space, gradient_repeat_mode, gradient_reverse).
And some cleanup in context.pdb.
This is still WIP, nothing in the edit group is depcreated yet.
First WIP commit, adds:
- enum GimpGradientBlendColorSpace { RGB_PERCEPTUAL, RGB_LINEAR }
- linear blending mode for gradient segments
- tool options GUI for the blend and paint tools which use gradients
Since commit 9c8a8ae576, we don't run gimp_quit(), which properly quits
the plug-in executable, to make sure that GIMP gets the information that
it crashed. Instead quit with `exit (EXIT_FAILURE)`.
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
Drmingw already added its own exception handler which generates crash
traces in a text file, for plug-ins as well. This additional handler is
run after Drmingw handler and allows us to do things on our own, and in
particular we could display the content of the debug traces.
Right now it simply prints these to stderr, which actually won't be of
much use on Win32, first because the console is deactivated on stable
releases, also because after tests, it doesn't look like even running
GIMP from cmd outputs to console either.
We currently don't use the same debug dialog as the core on purpose,
because we don't want everyone to send us traces for every unmaintained
third party plug-ins out there. But we should definitely allow easier
trace possibilities at some point, first to improve/debug our own core
plug-ins, and also to help third party plug-in developers!
So this commit is not making visible changes yet but is actually a first
step towards these debugging goals.
When ending with gimp_quit(), GIMP was not displaying the "Plug-in
crashed" error dialog, which is not good, since we lose the crash
feedback for plug-ins. Just let the plug-in continue its normal run in
order to get the error dialog.
Also protect the tracing functions, which are not working on Win32.
SIGABRT was in the switch list in gimp_plugin_sigfatal_handler(), but it
had not been properly handled with gimp_signal_private(), making this
switch case useless. Fix this oversight, and while doing so, move it in
the "fatal error" list for which we may generate stack traces, similarly
to core signal handling. Indeed this signal can definitely happen during
various kinds of common bugs and needs to be debugged.
This property is currently only used for gimp_edit_blend() to control
how are computed distances. In the future, it could be used for more
functions making use of "gegl:distance-transform" operation, or even for
other algorithms, if relevant.
This new property obviously comes with 2 new PDB calls:
gimp_context_get_distance_metric() & gimp_context_set_distance_metric()
The enums have to be menually registered in pdb/enums-external.pl.
Currently supports enums from GEGL only.
Add enum GeglDistanceMetric as first external enum.
Our composite modes don't correspond directly to the Porter-Duff
operators after which they're named, and these names aren't too
descriptive anyway.
Rename the composite modes as follows:
Source Over => Union
Source Atop => Clip to Backdrop
Destination Atop => Clip to Layer
Source In => Intersection
Update relevant code, including UI text, enumerator names, function
names, and action names.
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.
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.
Our own implementation is much better.
I don't make it into a GUI yet, but at least the CLI option will use the
new implementation in plug-ins as well, which will be quite useful.
... procedure call.
This is needed for plug-ins which depends on other plug-in's procedures.
If for instance, the second-level plug-in is interrupted interactively,
we don't want to process this as an error but as a cancellation.
Therefore we need to know the returned value of the plug-in. Currently
only way was to use gimp_get_pdb_error() but that was returning a
human-readable error, not a computer-processable error.
gimp_image_metadata_save_prepare() now back to suggesting metadata
flags, but this time with reasonnable base. It indeed uses the presence
of particular metadata, but also whether the preferences asks for this
metadata to be exported by default or not.
The returned flags should not be called "suggested" flags anymore.
Having metadata available in the work image does not mean we want them
exported absolutely, which can be a security risk, especially for the
metadata which are there from the imported image.
Add "clamp-input" (which clamps the input values to [0..1])
and "clamp-output" (which clips the final result to [0..1]),
properties, parameters and GUI to:
- GimpLevelsConfig
- GimpOperationLevels
- The levels tool dialog
- The gimp_drawable_levels() PDB API
The old deprecated gimp_levels() PDB API now sets both clamping
options to TRUE which restores the 2.8 behavior.
Also reorder some stuff in GimpLevelsConfig and elsewhere so the
levels parameters are always in the same order.
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
