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.
Still the same problem as ever with the Python binding where we have a
hard time creating GParamSpec, hence we make them from object
properties.
See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/227#note_570031
But then again, the Python binding way to create GObject properties does
not seem to give us a way to use our custom param types (or I didn't
find how). So when I create a property with Gimp.RGB type in Python, it
doesn't appear as a GIMP_PARAM_SPEC_RGB to our C code, but as a
G_PARAM_SPEC_BOXED. So my trick is to check the value type instead.
Note that I check the default value, but in reality it doesn't seem to
work much either. Better than no support at all anyway.
Used for instance if a plug-in had a GimpParasite argument (or aux
argument), which might not seem too useful at first. But anyway we
propose the type, so let's support it properly.
And actually I am going to use it in the next commit as a trick to save
binary data in stored last values for a plug-in.
… drawable array instead of a single drawable.
Instead of expecting a single drawable, GimpImageProcedure's run()
function will now have an array of drawable as parameter.
As a consequence, all existing plug-ins are broken again. I am going to
fix them in the next commit so that this change can be easily reviewed
and examined if needed later.
I only fix the Vala demo plug-in now (or rather, I just use the first
layer in the array for now) because otherwise the build fails.
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.
Negative int values were not correctly handled because value.v_int is unsigned
causing a conversion to a large positive value.
To fix this we cast it to gint64 first before making it negative.
In gimp_config_deserialize_fundamental(), we can't use
g_value_set_static_string() because that will in the end pass the
GScanner's temporary scanner->value.v_string to
GObject::set_property(), and depending on set_property()'s
implementation, we might not dup the string (for example objects
created via gimp_config_type_register() will simply use g_value_copy()
and end up with a dangling pointer as a string member).
Especially need to watch out with forgetting `(array)` and `(out)`
annotations, as they can really give a different API in certain (if not
most) bindings.
gimp_config_type_register() currently overrides GimpConfig::equal()
to only compare the properties of the most-derived type. However,
this prevents the properties of GimpOperationSettings from being
considered during comparison of operation-config objects. Instead,
don't override GimpConfig::equal(), and rely on
GIMP_CONFIG_PARAM_DONT_COMPARE to exclude specific base-class
properties from comparison.
Allow calling gimp_scanner_new_string() with a NULL `text` and a
negative `text_len` (which is interpreted as 0), instead of
requiring `text_len == 0` in this case. This allows passing a
negative `text_len` unconditionally to infer the length, even when
the string may be NULL.
In gimp_config_deserialize_fundamental(), cast integer token values
to the target value type *before* negating them, to avoid
performing unsigned negation, which can result in a positive value
when cast to the target value type (in particular, when the target
value type is float/double).
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Allow passing a non-NULL `pspecs` with `n_pspecs == 0` to
gimp_config_type_register(), in particular since
g_object_class_list_properties() may return such values.
There is at least one valid case of a config type registration with no
parameters: when registering the gegl:nop operation. This is the default
case when running the GEGL operation tool. See implementation of
gimp_filter_tool_get_operation().
Therefore we ended up crashing GIMP just by calling this tool.
It now supports all GParamSpecs possible on the wire protocol, except
the ones that are implemented in app/ and libgimp/ (image, drawable,
...) and are not visible to libgimpconfig
GimpConfigWriter contains several constructors with the convention
`gimp_config_writer_new_* ()`. This will lead to problems however with
languages like Vala, where it cannot disambiguate the following:
```
// calls config_writer_new_string()
Gimp.ConfigWriter w = new ConfigWriter.string("xxx");
// calls config_writer_string()
w.string("xxx")
```
Using `from_` in constructors is general practice in GObject-bsed
libraries because of this.
This also fixes an error when trying to use vapigen on the GIMP .GIR
file.
The `GIMP_CONFIG_PROP_*` macros do not automatically set
`G_PARAM_STATIC_STRINGS`, which means each property that uses such a
macro does not have this flag set by default (and almost none set it
themselves). By adding `G_PARAM_STATIC_STRINGS` to
`GIMP_CONFIG_PARAM_FLAGS`, we can prevent this from happening, which
should lead to some unnecessary string copies being prevented.
libgimp is anyway processed at the very end after all other libgimp*
were built. This way, it also fixes#3746, by removing the $(top_srcdir)
everywhere from introspected files, hence making the build work again
with older automake.
Basically this commit makes sure that all return values that are marked
as "Returns:" also have a `(nullable)` annotation if it is mentioned on
the same line that NULL can also be returned.
This will prevent a few problems in GObject-introspection.
Jehan