… 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.
During instantiation, the widget bypassed saving the PROP_DIGITS state
because the spinbutton was not populated, leaving digits at 0. This
forced the widget into an integer state, causing step calculations to
break for small fractional ranges (e.g., 0.001 to 1.0).
Added G_PARAM_CONSTRUCT to the digits property and moved the internal
assignment outside the spinbutton check so the correct initial state
is saved immediately.
Added a check to ensure step and page do not go out of range.
Same patch as cb552d3d, just applied to GimpPrefsBox.
This was visible in the Preferences Dialog, where the same
unnecessary pop-up appeared in the side panel.
When we copy and paste a vector layer,
we need to reattach its path to the
(potentially) new image. Similar to what
we did for NDE filters in 8db97f4e,
we convert the existing path if necessary
before continuing with the gimp_item_convert ()
process. This prevents several CRITICALs,
for instance when copying a group that
contains vector layers rather than the
vector layers directly.
This reverts commit d91a8b2abe.
As reported by Liam on #15824, this commit was clearly wrong and
reintroduced the old cropping bug with multiple filters. Reverting.
The next commit was likely good, though the real hanging bug is — as far
as my test go — in the GEGL op itself. This second commit 75e665f0ed was
improving things, but obviously, as the bug is still in the op, it can
still be triggered. We'll have to fix the source bug next.
This patch replaces adding a custom widget
to the Path Export dialog with a built-in
combobox from gtk_file_chooser_add_choice ().
This makes our code more compatible
with a future port to native file dialogs
in GTK3, without a loss of functionality.
Ah my previous commit was working fine with a selection in the "Use the
selection as input" case, but was still hanging when "Use the entire
layer as input" was chosen.
The detection of whether we were the first filter was not working fine
when adding a new filter. Now this should work in all cases.
I don't revert the previous commit, because I think it's fine anyway.
When we have a selection, unconditionally adding a cropping-before node
on the selection boundaries seems logical to me.
Hopefully it doesn't bring back any of the cropping issues we had on
filters, but so far I could not reproduce any.
