While listing the file formats, I could not find the format, because it
was labelled differently.
This doesn't break the strings since the longer string already existed.
It's mostly copy-pasting of dev versions' metadata, with reordering per
category.
I didn't copy features which were backported in the 3.0 series since, or
still in playground, some of the less visible features, what looks a bit
more like fixes than features, regrouped some points when relevant, etc.
… from a plug-in.
The value is accepted by the current specification of "channel" but it
is actually not supported and would end up crashing the core process.
The real fix which should happen would be to make GimpParamSpecEnum
usable in libgimp, and be able to pass its spec through the PDB. Then we
could use this param spec instead of GParamSpecEnum for such property
not supporting all values in an enum.
Note that with the current fix, the "gimp:curves" filter will silently
refuse the Luminance channel when passed as "channel". It is not ideal.
But it's better than crashing the whole of GIMP!
… gimp_drawable_curves_spline().
We can now run directly "gimp:curves" operation, both destructively or
non-destructively, but also setting the TRC, as well as individual point
types (when the curve is of type "smooth" instead of freehand).
This is much more powerful!
In particular, I am getting rid of several of the properties, which are
really not that good (and even bogus for some, such as "n-points").
Properties tied together like this (number of elements stored in one
prop applying to the array stored in another prop) are often a bad idea
and only end up in messy code ending up in inconsistencies.
Instead let's use signals. I am keeping the "n-samples" for now as it
can clearly be considered more "stable" than "n-points" and not meant to
change.
We'll also have to make a decision on whether we really want to keep the
samples API in libgimp, or drop all current sample functions. Right now
we cannot actually create meaningful sample points.
Thanks to various improvements on babl and GEGL repos they now build cleanly.
So, let's take advantage of Clang senstive semantic analysis on future builds.
For now, this is limited to such projects and on GNU Clang and Apple Clang,
since there is still a bit of work to do on Clang-CL (MSVC) side.
Adds a GimpCurve object and functions in libgimp.
Rather than creating a GimpCurve object in core and
passing it back and forth, we just pass the attributes
and reconstruct it across.
In the future, we may combine this with the app/core one
and put it in libgimpbase.
I think the previous code should be OK, but I had some criticals when
painting with a paint tool in the area which got extended:
> (gimp:577203): GLib-GObject-CRITICAL **: 21:37:08.402: value "-31" of type 'gint' is invalid or out of range for property 'y' of type 'gint'
It looks like there lingering pieces from the negative offset in the
buffer, which is probably a bug in GEGL?
Anyway let's go the shorter route for now, which is to copy the buffer
with a different offset. I don't think it's less efficient either
anyway.
When merging filters whose rendering was expanding in negative
ccordinates, I realized that the drawable was not properly resized (it
was resized properly when the width/height increased, but not when the x
or y points became negative, even though this "cropped" part still
showed… until you saved and reloaded your XCF!).
The problem is that drawable buffers are always stored with (0, 0)
top-left and this was just confusing our existing code. So let's check
when trying to set a buffer with a non-(0, 0) origin, and update the
offset subsequently.
I hesitated with an alternative implementation which was to edit the
buffer applied to the drawable in gimp_drawable_merge_filters(). But I
figured this would be more future-proof for other similar cases, though
I hope I did not break any use case where this was actually considered a
normal case.
