because we were simply destroying the proxy hashes when the last
procedure is done. Now we run gimp_plug_in_destroy_proxies() with the
right flag from gimp_plug_in_pop_procedure() before destroying the
hashes and get the proper debug warnings.
move the code to gimpparamspecs-body.c and include it from both app/
and libgimp/. They are the same apart from a minor difference which we
Also share the entire libgimp/gimpparamspecs.h header with the core.
No GimpParamSpecItem subclass needs its own validate function,
checking against pspec->value_type and gimp_item_is_vaid() in
gimp_param_item_validate() is good enough, no item ID can change its
type during the lifetime of the proxy.
GimpDisplay contains only the ID logic and the "gimp" and "config"
pointers, and lives in the core.
GimpDisplayImpl is a subclass and contains all the actual display
stuff. The subclass is only an implementation detail and doesn't
appear in any API.
Remove all hacks which pass displays as gpointer, GObject or
GimpObject through the core, or even lookup its type by name,
just use GimpDisplay.
which call gimp_item_get_by_id() and additionally check if the
returned item has the right type, and return NULL if not.
This is both shorter and more readable than
layer = GIMP_LAYER (gimp_item_get_by_id (id));
and additionally makes sure we don't cast e.g. a non-layer with
GIMP_LAYER(), which will give criticals but shouldn't, because the
wrong IDs can come from anywhere and are an input problem and not a
programming error (criticals are for programming errors).
Even when the function names may have stayed the same in most cases, the
API has changed. The "Since:" tag must therefore be bumped.
Also adding docs for gimp_drawable_get_sub_thumbnail_data() which had
none.
Basically creating a GParamSpecObject with type GimpImage would be
synonym to creating a GimpParamSpecImage (and similarly for items,
drawables, layers, and so on).
The only missing feature is therefore none_ok when using
GParamSpecObject (or to be more accurate: it implies none_ok=TRUE).
This is particularly needed for the Python API where a bug prevents to
manipulate GParamSpec types and pass them back to libgimp. Hence we want
to manipulate object specs using the binding specific API instead.
It used to work fine but this specific piece of code got removed by
commit 392f00baf5. This now works again fine.
- hand out and leak proxy object objects to legacy API like candy,
bypassing the factory in GimpPlugIn, because there is no plug-in
singleton.
- gimpgpcompat.c: image, item etc. are now objects, simply forgot this
file.
Need to push the current procedure around the entire body of
gimp_plug_in_proc_run_internal() because
_gimp_gp_params_to_value_array() needs access to proxy objects now.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
Add an additional ref count to all proxies handed out by
GimpPlugIn, and when destroying the proxies, warn about any
proxy that has been unrefed, or additionally refed.
This catches and warns about only one broken unref, any more will
simply crash like before.
Seems underscored APIs are not visible on Win32. Anyway even if we fixed
this, this would only be temporary as all these deprecated APIs are only
meant to stay around temporarily, then be actually unavailable.
I hesitated to actually undeprecate the `_gimp_*_is_valid()` (like
making a `gimp_image_is_valid_id()` API for instance) but this is
actually quite similar to just create the GimpImage: if
gimp_image_get_by_id() returns NULL, then the ID was not valid.
We now have both variants, one returning a GList, and another
returning an array. Turns out that while a list is often nicer,
sometimes a random-access array really keeps the code much simpler.
Adapt all plug-ins, and clean up a bit (like use g_list_reverse() once
instead of iterating the list reversed).
Same for returned value though it seems we have no function with none_ok
as return value. At least we have the rule in the generation script for
when this will happen.
Michael Natterer