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.
We have code for this in gimp_proc_browser_dialog_new(), but it cannot
be moved in the object init() because this is a construction-time only
property. So this needs to be passed from the python call too.
Otherwise, if run in gimp_proc_browser_dialog_new(), this initial search
does not happen when constructing with g_object_new(). This is
especially bad for non-C plug-ins as gimp_proc_browser_dialog_new() is
not introspectable because of variable arguments.
As mentioned in issue #1777, exporting non-animated WebP images was
only keeping the current layer.
Mimick file-gif-save.c: display the encoding settings pop-up earlier
so that gimp_export_image() can merge the layers unless "As Animation"
is enabled. Call gimp_image_get_layers() directly in save_image() in
case the layers were merged (for clarity because layers are used only
for animations).
Which return proper GParamSpecs. Incuding some useless testing code in
gimp_procedural_db_proc_info(), to make sure things work, will go away
again soon.
Right now, we get the following warnings when building the docs:
> gtk-doc.xsl: For acronym (nullable) no value found
This is because we're not adding the generated annotation glossary to
the docs sgml (presumably because we didn't need it as we didn't use
GObject-Introspection yet). This commit adds those lines and thus fixes
the warnings.
Also generate comments like "Must be freed with g_free()" for all
return values instead of manually and inconsistently having them on
some return values only.
allow to pass booleans and enums to GIMP_TYPE_INT32 arguments. We
didn't have them in the old plug-in API, and being less strict allows
for booleans and enums being passed to old procedures transparently.
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
