In GimpDrawable::set_buffer(), and the corresponding
gimp_drawable_set_buffer_full() function, take a bounds rectangle,
which specifies both the drawable's new offset and its new size,
instead of only taking the new offset. In
gimp_drawable_real_set_buffer(), set the item size according to the
rect dimensions, instead of the buffer dimensions. The rect's
width/height may be 0, in which case the buffer's dimensions are
used.
Adapt the rest of the code.
We do this in preparation for maintaining the drawable's bounding
box separately from its logical bounds, allowing the drawable
content to extend beyond its bounds.
which must be called by GIMP_EXTENSION procedures when they are ready
to run their temporary procedures. Move gimp_extension_ack() to
gimpobsolete.[ch].
This is especially true since procedures are defined by plug-ins,
possibly third-party. So they may not have a first run mode parameter.
Also we don't want plug-ins to generate CRITICALs in the core
application.
Therefore before trying to get and/or set the run mode parameter, always
check that this first parameter exists, and if so, is it a GimpRunMode
enum?
Fixes similar errors:
> GIMP-CRITICAL: gimp_value_array_index: assertion 'index < value_array->n_values' failed
Moreover it also makes sense to allow plug-ins to not have such
parameter. What if you make a plug-in which always work in a single mode
and don't ever plan/want to make it work interactively for instance?
Lastly old Python 2 plug-ins didn't even have a run mode parameter (I
guess our old Python 2 wrapper was getting rid of it?).
Basically the number of parameters comes from plug-ins which could write
whatever crap on the wire. I had a case (playing with Python plug-ins)
where GIMP tried to allocate insane amount of parameters. This is bad
as it allows third-party plug-ins to crash GIMP core.
Instead only *try* to allocate, then return as though there were no
parameters if allocation fails. I also print some info on stderr, but
don't output WARNING/CRITICAL (this is not a core error, but a plug-in
error). Fixes:
> GLib-ERROR **: 16:30:23.357: gmem.c:135: failed to allocate 187186442160 bytes
... gimp_procedure_new_return_values().
When we see how this has been used in help or goat-exercise plug-ins so
far, we clearly see that we expect this function to be used as last call
in a run callback. Well we could save the result, free the error, then
return the result, but it's cumbersome.
So instead let's officially expect gimp_procedure_new_return_values() to
take ownership of the GError (i.e. it will free it in the end).
For this reason, remove the `const`.
The GimpPlugInClass:: prefix is important, otherwise GObject
Introspection tools don't take these docs/annotations into account (and
most methods ended up not introspected at all with annotations).
Also fix some typos/sillinesses (missing colon; useless (out) on Returns
value and useless (element-type) for easily scannable type).
- We were leaking the result of query_procedures(). At least as far as
the example port (help plug-in) shows, it returns a newly allocated
array of strings, NULL-terminated. This needs to be freed by the
calling code.
- Add documentations on GimpPlugIn virtual methods so that people know
what to do with them, and what kind of data to return (like
NULL-terminated array of procedure names for simple freeing).
- Fix _gimp_plug_in_init() which was registering the query procedures
instead of the init ones. For this, I added a `init` boolean parameter
to gimp_plug_in_register().
- Finally check the return value of gimp_plug_in_create_procedure(). It
is possible that a plug-in not properly implemented returns NULL and
we want to avoid the CRITICAL. Still output a warning as this is
likely a plug-in development bug.
Recent commits broke the Python plug-ins again because the old API is
not introspected anymore. Of course, by release of GIMP 3, we should
probably remove this deprecated API from introspection. But first, we
have to figure out how and if the new API can be used in bindings.
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
This reverts commit 833666d462.
The _pdb files are an implementation detail and we do not want
separate doc sections for them, the conflicts need so be resolved in
another way.
Otherwise we get a few duplicate sections since some of the non-PDB
files are named similarly.
Fix this GObject introspection warning and other similar warnings:
> libgimp/gimp_pdb.c:28: Warning: Gimp: multiple comment blocks
> documenting 'SECTION:gimp:' identifier (already seen at gimp.c:129).
Ell