While the work on NULL-terminated array types make it much easier in C,
bindings don't have enough information to create native array/list types
in some generic functions such as g_object_get|set(), or else we just
don't know the right annotations to use for this to be possible. This is
report gobject-introspection#492.
So for the time being, we are creating dedicated functions for GeglColor
arrays and for other core object arrays (arrays of images, items, etc.).
E.g. in Python, while you can set a single GimpImage like this:
> config.set_property('image', image)
… you need to set a list of images like this:
> config.set_core_object_array('images', [image1, image2])
Avoid the stack smashing bug from yesterday in other functions.
Additionally to fixing other functions, do not cast the pointer to size
in the PDB generation scripts so that we can quickly spot such bugs in
the future, through compilation time warnings, instead of hiding them.
As reported by Anders in !1919. This is because
gimp_pdb_execute_procedure_by_name() now expects a proper GimpArray for
float and int arrays, not a C array preceded by a size value.
Generated libgimp functions' arguments are normally tested through the
PDB, so that you get proper error messages when trying to call a
function with invalid arguments.
This is not true anymore for array arguments since the size argument is
not a PDB arg, only in the C function. Therefore I'm adding an
infrastructure asserting on invalid size, using the same PDB type
annotations as other args. It is important to assert valid input on
plug-in side (i.e. libgimp) so that the core doesn't make any assumption
on having received valid input when it has not.
Also changing size argument of gimppainttools PDB-generated functions to
proper gsize.
Yet they still are generated libgimp functions' arguments.
For instance gimp_context_get_line_dash_pattern() still has a num_dashes
integer argument and a dashes C array, but when calling the PDB
procedure "gimp-context-get-line-dash-pattern", we only set the
GimpArray.
This will allow simpler direct PDB calls too, included in script-fu,
where the size argument is really redundant.
PDB code is now looking directly into the GimpArray length for
determining the data length.
Also adding a 'size' argument (number of elements, not bytes) to
gimp_value_(get|dup)_int32_array() to make it actually introspectable.
Until now, it was somehow introspected but was segfaulting on run.
I.e. that, e.g. in Python, calling Gimp.value_set_int32_array(v, [1, 2, 3])
followed by Gimp.value_get_int32_array(v) would actually make a
segmentation fault. Now the binding works flawlessly.
This will also make these functions much more usable in general.
… PDB type.
This is a first step for #7369. Clearly our GimpObjectArray was meant to
be used with C arrays, hence the wrapper function
gimp_value_set_object_array() which was taking a C array and actually
creating and setting a GimpObjectArray.
This is why our new type is actually a C array aliased as a boxed type
and containing its own size (thanks to NULL-termination).
Eventually GimpCoreObjectArray is meant to replace GimpObjectArray.
The only issue is that such a type does not allow NULL as a valid
element in such an array, but fact is that I don't think we currently
have any use case where this matters. If ever such a case arise in the
future, we may introduce back GimpObjectArray.
In this first commit, I replaced all itemarray PDB types with a new
drawablearray using this new boxed type when relevant.
This patch adds a pdb getter/setter for GimpStrokeOptions'
emulate-brush-dynamics property. This allows users to change
the "Direction" of strokes via Script-fu/Python API calls.
Since we consider it private, yet it's still needed in libgimp and app,
let's at least put it in a private header because there is no need for
people to try it out.
I'm also editing a bit the annotations for gimp_main() and GIMP_MAIN().
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.
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.
gimp_image_metadata_load_prepare(), gimp_image_metadata_load_finish()
and gimp_image_metadata_save_finish() are only ever used internally now,
so there is no need to expose them.
If we realize that we need them as public functions later, or someone
reports a valid use case, we can always bring them back later.
Also improves a bit various annotations.
On generating our PDB files, we were
getting warnings about uninitialized strings.
This is because descriptions and authors
had been left off three .pdb files. Adding
these in resolved the warnings.
A new PDB author entry was also added
for Idriss Fekir.
These function names look like they should be applied to a
GimpPaletteEntry, which is a type which doesn't exist in libgimp. This
naming is much more appropriate.
Fix a generic case when gimp_window_set_transient() is called on an
already mapped window: the handle argument was missing.
The part in bmp-export though, in fact, I am still a bit at a loss.
Somehow calling gimp_window_set_transient() was making the dialog not
showing up at all, yet kinda blocking the bmp plug-in (waiting for a
response to the non-displayed dialog) and various features in the main
GIMP GUI too.
Calling gtk_widget_show() first, before setting transient was enough to
make the dialog finally work as it should, but this is really not ideal.
I compared to other cases in other plug-ins where the set_transient()
function was called before the dialog was shown and it is working fine.
I just cannot find the proper reason. So this will do for now.
They are now replaced by the more generic gimp_palette_[gs]et_colormap(),
hence making less of a particular concept of "image colormap". It's just
a palette attached to the image (and restricted to the image format).
It was an equality because I think the conversion from palette format to
"RGBA float" should go through the exact same babl code path, however it
is done in the API. And that is the case on my machine where I get
indeed perfect equality. But apparently not on the CI.
Though I guess investigating further would not be a bad idea, let's
consider this a minor issue (as a general rule, comparing float with
epsilon is still a recommended software usage), and just add a comment.
GBytes are a bit annoying to handle, so I'm renaming the PDB procedure
to a private _gimp_palette_get_bytes() instead, and making a wrapper
function which returns a C array and both the number of colors or number
of bytes. The latter is needed for introspection (otherwise the binding
can't know the size of the C array), but for the C API, both these
returned integers can be considered redundant (since one can be computed
from the oher), so only one at a time is mandatory.
When we want to set a full palette based on an existing one, no need to
request the full colormap from core to libgimp then back. Just set the
palette which is nothing more than an empty shell around a resource ID.
Jehan