Alx confirms that "Drop shadows, Inner Shadows, and Outer Glow are all
layer styles in Photoshop", which I wasn't certain about (this software
has different concepts for what is basically just effects). So let's
combine in a single item.
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.
