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.
Use direct GType comparisons where possible, special case layer
because it has core subclasses but only one PDB type, special case
display because it's not visible from app/plug-in/, make code for
GPParamDef and GPParam look the same.
Turn GimpPlugIn into the main factory for all proxies and keep the
main hash tables there. The hash tables keep the initial reference.
For each GimpProcedure::run(), have s "sub-factory" which hands out
proxies to the actual procedure code. Each run() has hash tables of
its own which hold additional references. When run() is done, get rid
of its hash tables and their references, *and* drop the main plug-in
reference counts from the global hashes if the proxies' refcount has
dropped to one.
It is theoretically possible for an id to be reused. Normally here this
should not happen, since the previous item would have been removed from
the hash table anyway, when it got destroyed. Let's still be thorough.
This means that images' ownership is not given to caller in particular.
libgimp will now keep a reference of all GimpImage-s it creates and
return this same reference if called again. It also means that you can
now compare images by pointer comparison (as 2 GimpImage objects
representing the same image ID will be equal).
Obviously as a side effect, gimp_image_list() is changed to (transfer
container) as you must only free the container now, not the elements.
Also various other functions creating new images are now (transfer none)
too.
Long-time plug-ins will have to be taken in consideration in a further
step (we currently never free GimpImage for destroyed images in
particular).
I.e.: gimp_image_get_(layers|channels|vectors)(), gimp_image_list() and
gimp_item_get_children().
Instead of returning an array of IDs, these will now return a GList with
the right objects ready to use.
No need of is_id_arg() anymore in pdb/lib.pl. Let's reuse the {id}
value. Also I had to add an additional trick for GimpDisplay which we
will now generate as such in libgimp PDB files, but still need to show
as GimpObject on app/pdb/.
As previously, only the new classes and the PDB generation for a first
step.
I did the same trick with GIMP_DEPRECATED_REPLACE_NEW_API macro, apart
for some minor widget API to preview drawable, which I will fix right
away in our plug-ins.
Though it is still possible to use an image ID as procedure parameter,
it is now possible to pass a GimpImage GParamSpecObject.
Over the wire, this will transform back and forth into a GimpImageID,
totally transparently for the plug-in which will only always get a
GimpImage.
Same as previous commit: by default the new API will be used. But if a
plug-in builds with GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same
function names will call the old API with ids.
By default the new API will be used. But if we build with
GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same function names will
call the old API with ids.
This way, we don't have to update all our plug-ins at once (which I
tried and is very tedious work).
Note that bindings won't have access to the deprecated API at all.
This means that all functions which were returning or taking as
parameter an image id (as gint32) are now taking a GimpImage object
instead.
The PDB is still passing around an id only over the wire. But we create
an object for plug-ins to work on.
This is quite a huge API break, but is probably the best bet for the
future quality. It will make nicer API instrospection (and nicer API in
binding), will fix the issues with pspec on GimpImageID in Python
bindings (which makes the current Python API unusable as soon as we need
to work on images, which is most of our plug-ins!), etc.
Also it will allow to use signals on images, which will be a great asset
when we will finally have bi-directionnal communications (i.e. plug-ins
would be able to connect to image changes, destructions, and whatnot).
that make dealing with value arrays easier and shorter, e.g.
g_value_get_boolean (gimp_value_array_index (args, n)):
becomes:
GIMP_VALUES_GET_BOOLEAN (args, n);
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
And always pass URIs to all file procedures, the ones what didn't
register as "handles remove" will only ever get local file:// URIs.
Change all file plug-ins (also legacy ones) to expect URIs instead
of filenames, and convert to local paths in the plug-in.
The wire protocol should now be almost 100% clean of non-UTF-8 strings.
which looks much like gimpconfig-params.h and contains macros
(e.g. GIMP_PROC_ARG_BOOLEAN() and GIMP_PROC_VAL_BOOLEAN()) for all
GimpProcedure argument and return value types supported by the
protocol, and makes the boilerplate of setting up a procedure more
readable and much less indented.
This file is C-only and not introspected.
