… 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.
… the public API.
This was initially proposed by Niels De Graef in !101, and though I
still think this is much less practical for day-to-day development, it
is actually much nicer for the public part of the API. So let's use
these only in public libgimp* API only, not in core.
I actually already started to use these for some of the libgimpwidgets
classes and am now moving libgimp main classes to these macros.
* It doesn't expose the priv member (which is completely useless for
plug-in developers, only to be used for core development).
* It forces us to never have any variable members in the public API
(which we were doing fine so far in newest API, but it's nice to be
enforced with these macros).
* When using G_DECLARE_FINAL_TYPE in particular, it adds flexibility as
we can change the structure size and the members order as these are
not exposed. And if some day, we make the class derivable with some
signals to handle, only then will we expose the class with some
_gimp_reserved* padding (instead of from the start when none is
needed). Therefore we will allow for further extension far in the
future.
Moreover most of these libgimp classes were so far not using any private
values, so we were declaring a `priv` member with a bogus contents just
"in case we needed it in future" (as we couldn't change the struct
size). So even the easiness of having a priv member was very relative
for this public API so far (unlike in core code where we actually have
much more complex interactions and using priv data all the time).
This fixes bugs introduced in commit a7c59277fb where I obviously didn't
properly checked all the places where gimp_selection_float() was used
after its parameters changed.
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.
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).
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.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2006-11-03 Michael Natterer <mitch@gimp.org>
* libgimp/gimpbrushes.c
* libgimp/gimpgradients.c
* libgimp/gimpimage.c
* libgimp/gimplayer.c
* libgimp/gimppalette.c
* libgimp/gimppalettes.c
* libgimp/gimppatterns.c
* libgimp/gimpselection.c: also let all non-generated deprecated
functions see their declarations.
2004-11-16 Michael Natterer <mitch@gimp.org>
* tools/pdbgen/pdb/image.pdb
* tools/pdbgen/pdb/selection.pdb: entirely removed the deprecated
functions "selection_clear", "image_set_cmap" and "image_get_cmap".
* app/pdb/procedural_db.c: and added them to the compat hash table
because they have undeprecated replacements with identical
signature.
* libgimp/gimpselection.[ch]: added gimp_selection_clear() here
instead because we need the symbol in libgimp.
* app/pdb/image_cmds.c
* app/pdb/internal_procs.c
* app/pdb/selection_cmds.c
* libgimp/gimpselection_pdb.[ch]: regenerated.
2000-06-01 Michael Natterer <mitch@gimp.org>
Sven Neumann <sven@gimp.org>
Completed the new file structure. Yet only few of the _pdb.[ch]
files are based upon generated code and nothing is really
autogenerated...
* app/Makefile.am
* app/gdisplay_cmds.c -> app/display_cmds.c
* app/gimage_cmds.c -> app/image_cmds.c
* app/gimage_mask_cmds.c -> app/selection_cmds.c
* app/internal_procs.c: related change
* libgimp/Makefile.am
* libgimp/gimp.h
* libgimp/gimp_pdb.h
* libgimp/gimpdisplay_pdb.[ch]
* libgimp/gimpimage_pdb.[ch]
* libgimp/gimpselection_pdb.[ch]: replaced with code based on files
generated using pdbgen
* libgimp/gimpchannelops_pdb.[ch]
* libgimp/gimpcolor_pdb.[ch]
* libgimp/gimpedit_pdb.[ch]
* libgimp/gimpfloatingsel_pdb.[ch]
* libgimp/gimpgimprc_pdb.[ch]
* libgimp/gimptexttool_pdb.[ch]
* libgimp/gimptools_pdb.[ch]
* libgimp/gimpundo_pdb.[ch]: new files based on generated code
* libgimp/gimpgradientselect.[ch]
* libgimp/gimpimage.[ch]
* libgimp/gimpselection.[ch]: new files wrapping around the
autogenerated PDB wrappers as found in *_pdb.[ch]. This is necessary
since the number of parameters or their order is different from the
PDP calls.
* plug-ins/common/CEL.c: plugged memleak
* plug-ins/common/aa.c: removed compiler warning
* tools/pdbgen/Makefile.am
* tools/pdbgen/groups.pl
* tools/pdbgen/pdb/gdisplay.pdb -> display.pdb
* tools/pdbgen/pdb/gimage.pdb -> image.pdb
* tools/pdbgen/pdb/gimage_mask.pdb -> selection.pdb
* tools/pdbgen/pdb/channel_ops.pdb
* tools/pdbgen/pdb/color.pdb
* tools/pdbgen/pdb/edit.pdb
* tools/pdbgen/pdb/floating_sel.pdb
* tools/pdbgen/pdb/gimprc.pdb
* tools/pdbgen/pdb/text_tool.pdb
* tools/pdbgen/pdb/tools.pdb
* tools/pdbgen/pdb/undo.pdb: made them create libgimp code
Jehan