This patch ports the Add/Subtract mode
shortcuts from GimpSelectionTool to
GimpPaintSelectionTool, implementing
the unfinished gimp_paint_select_tool_modifier_key ()
function. The UI itself is left unchanged.
When setting a new palette, we must not use the new palette format
restriction (especially if it has none!), but the indexed image's
format, which is unchanged anyway. So move the call to
gimp_palette_restrict_format() into gimp_image_colormap_update_formats()
and use the correct format to restrict to.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/12108#note_2238182
gimp_size_entry_eevl_unit_resolver () loops through all valid units
to find a match for user's inputted value in GimpSizeEntry.
It runs until gimp_unit_get_by_id () returns NULL, where it does a
final check on GIMP_UNIT_PERCENT.
Due to a small logic error, we kept setting the GimpUnit to
gimp_unit_percent () each time it was NULL, so the loop ran forever.
Per Jehan, this patch breaks the logic up so that we terminate the
loop once the percent check fails.
Some filters such as gegl:spiral have properties which limit
their width and height, separate from the gegl:crop nodes in
GimpDrawableFilter. As a result, they won't scale when the layer
or image is resized even if the crop is updated.
This patch checks if there's a "width" or "height" property with
the "output-extent" role in the filter, and updates those properties
to make sure it resizes correctly. Renders made from selections
are not modified, as the user specifically chose that size.
Building with clang i have "missing sentinel in function call" warning. The C callers to such functions use the C NULL definition (ie ((void*)0)), which is a valid sentinel. However the C++ NULL definition (ie 0L), is not a valid sentinel without an explicit cast to a pointer type.
Commit 5b981adc7f was not taking into account that on Windows, the
gimp_resource_select_*() functions were made invisible and still needed
to be in the def file.
So this makes the 2 functions technically still exposed in the binary
even though the functions stay officially private (they are not in
header) and people are not supposed to use them directly in plug-ins.
… to GIMP_PDB_PROC_TYPE_PERSISTENT, let's rename some procedures.
s/gimp_plug_in_extension_enable/gimp_plug_in_persistent_enable/
s/gimp_plug_in_extension_process/gimp_plug_in_persistent_process/
s/gimp_procedure_extension_ready/gimp_procedure_persistent_ready/
Even though it's not public yet (and won't really be for GIMP 3.0), I
created a new concept of "GIMP Extension" (.gex files) which bundles
various types of data for GIMP, such as plug-ins but also brushes and
other resources, themes, icons, etc.
Having 2 different concepts named the same is confusing, especially
since one of them is not really self-explaining IMO (why are "always-ON"
plug-ins called "extensions"?). So even though this is the older
concept, and since we are anyway massively breaking the API for GIMP
3.0, let's rename this older concept. "Persistent Plug-Ins" is much more
self-defining.
The Fade curve is meant to use the widget's foreground color. The current
code detects this by checking if the curve's predefined color has an alpha
value of 0 - if it does, INPUT_COLOR (i) returns NULL and sends a NULL color
variable to gimp_curve_view_set_curve ().
However, since the GeglColor port, the "color" variable is an empty
GeglColor object rather than a pure NULL value. Thus, the line was always
drawn with the default GeglColor value which is difficult to see in light mode.
This patch adds a tertiary conditional statement so that a pure NULL is sent if
the alpha value is 0, rather than the color variable.
