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.
It may be more efficient this way on supported compilers.
Some of the private functions cannot be marked with this macro because
they are used across GIMP libraries (for instance some libgimp
functions are used in libgimpui, but are not meant to be public), while
they are not made public in headers. These are still considered private,
as far as API stability is concerned.
Preferences > Image Import and Export tab has various Export Policies,
which are mostly for safety reasons. One may want to default at never
exporting specific metadata. This got broken and anyway the logic was
not good enough.
Now these policies are followed in interactive mode, unless an export
has already happened for this specific export plug-in on this specific
file (in this case, we reuse the last values). We don't want settings to
unexpectedly change in such a case.
In last-vals and non-interactive run-mode though, we don't follow the
Preferences policies, since in the former case, we want to reuse exactly
the same settings (e.g. we don't want an Export discarding metadata
which explicitly checked in the Export As) and in the latter case, it is
the developer's responsibility to set up expected options.
