Also fixes the passing of the resource param definitions through PDB.
There was some weird assumption, with a comment, in commit 73733335c8
that this was unneeded, which meant that we were not able to properly
recreate the right param spec over the wire.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
This is used in the generated GUIs for GimpChoice arguments, but also for
validation of property setting.
New functions:
* gimp_choice_set_sensitive()
* gimp_string_combo_box_set_sensitivity()
These will replace the int arguments used in place of enums. The problem of int
arguments used as list of choices is that it makes calling PDB functions very
opaque. This is especially bad when a list is long, so you constantly have to
refer to the documentation to understand what a series of numbers mean in
argument lists.
And the second issue is that plug-in developers have to manually maintain a list
of values both in the GUI and in the documentation string. This help text may
get out-of-sync, may end up with missing values or whatnot. Also if it is used
as tooltips, it makes for very weird tooltips in the graphical interface, with
an overlong technical list of int-values mapping which should ideally only be
made visible in the PDB procedure browser listing.
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
I assume that we won't need most of these explicitly in bindings, but
_if_ it's needed, then it's best to make sure that people don't struggle
because they don't have proper API without annotations.
This member of the GTypeInfo structure is the size of the object
instance (not of the parent instance). Let's fix it for all static type
registrations in this file, which had the same bug as commit
0eb6ff41cf.
Happy new year everyone!
like in the fix for issue #4392. Remove the reference to the issue
from gimp_param_spec_layer() because we can't have it in all places
that now do checks.
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
This partly reverts commit d999248d70.
The GimpStringArray is still very weirdly handled, in particular
regarding the difference of processing with static_data set or not.
Still this g_return_val_if_fail() was making more problems. It may come
back but will need more coding to handle the side effects.
Our GimpStringArray is so weird. We are obviously expecting it to be
NULL-terminated since, when we duplicate the data, we add one value.
Yet we were not checking that the stored data was NULL-terminated, in
particular when the string array is created with static data (in which
case, we use the input data as-is, without re-allocating).
Note that this doesn't fix the type mismatch Gimp.StringArray vs
Gimp.Array when introspecting.
all the stuff from app/core/gimpparamspecs.[ch] that is not about
image, drawable etc IDs, these will have to go to libgimp with
different implementations than in app/.
Jehan