Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
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.
Fix the dependency by making the stamp an actual (yet empty/no-op)
header file which is included by all generated source file. This way, we
ensure that meson rebuild .o files when the .pdb sources are changed.
This is the second solution proposed by eli-schwartz here:
https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080053413
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/.
So a value array can now we created like this:
array = gimp_value_array_new_from_types (&error_msg,
G_TYPE_STRING, "foo",
G_TYPE_INT, 23,
G_TYPE_NONE);
Change PDB generation to use this, which makes for much nicer code in
the libgimp wrappers, and only set arrays separately instead of all
values.
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).
All foo_pdb.c functions in libgimp regenerated. I have reviewed this a
dozen times, but please have a look, there might well be glitches and
our public API is sortof important...
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
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-09-13 Sven Neumann <sven@gimp.org>
* tools/pdbgen/pdb/color.pdb
* tools/pdbgen/pdb/drawable.pdb
* tools/pdbgen/pdb/image.pdb
* tools/pdbgen/pdb/layer.pdb
* tools/pdbgen/pdb/paint_tools.pdb
* tools/pdbgen/pdb/selection_tools.pdb: use the canonical form
when
refering to parameters in the procedure description.
2006-09-02 Michael Natterer <mitch@gimp.org>
Merged the "soc-2006-healing-brush" branch. That branch is now
officially closed and all further fixes and changes have to be
applied to HEAD.
Did some minor adjustments, mostly small indentation and spacing
fixes. Derive the tool from the newly introduced GimpBrushTool
which did not exist when the branch was created.
Thanks a lot to Kevin Sookocheff for this nice contribution!
* app/paint/paint-enums.[ch]: new enum GimpHealAlignMode.
* app/paint/Makefile.am
* app/paint/makefile.msc
* app/paint/gimpheal.[ch]
* app/paint/gimphealoptions.[ch]: the heal core and its options.
* app/paint/gimp-paint.c: register the heal core.
* app/tools/Makefile.am
* app/tools/makefile.msc
* app/tools/gimphealtool.[ch]: the heal tool.
* app/tools/gimp-tools.c: register the heal tool.
* app/tools/gimppaintoptions-gui.c: show the widgets that are used
by heal.
* app/widgets/gimphelp-ids.h: the heal help ID.
* tools/pdbgen/stddefs.pdb
* tools/pdbgen/pdb/paint_tools.pdb: the heal PDB wrappers.
* app/widgets/widgets-enums.h
* app/widgets/gimpcursor.c
* cursors/Makefile.am
* cursors/makefile.msc
* cursors/tool-heal.png
* cursors/xbm/tool-heal.xbm
* cursors/xbm/tool-heal-mask.xbm: a new cursor for the heal tool.
* libgimpwidgets/gimpstock.[ch]
* themes/Default/images/Makefile.am
* themes/Default/images/makefile.msc
* themes/Default/images/tools/stock-tool-heal-16.png
* themes/Default/images/tools/stock-tool-heal-22.png: new stock
icons for the heal tool.
* app/pdb/internal_procs.c
* app/pdb/paint_tools_cmds.c
* libgimp/gimppainttools_pdb.[ch]: regenerated.
2006-06-14 Michael Natterer <mitch@gimp.org>
* tools/pdbgen/pdb/[many].pdb: in help texts, refer to other
procedures using_c_syntax(). This way gtk-doc can cross-reference
them correctly in libgimp, and app.pl will transform them
'to-canonical-names' for PDB registering.
* app/pdb/[many]_cmds.c
* libgimp/[many]_pdb.c: regenerated.
2006-05-18 Sven Neumann <sven@gimp.org>
* tools/pdbgen/app.pl
* tools/pdbgen/lib.pl: removed code that used to fiddles with
the
argument descriptions.
* tools/pdbgen/pdb/*.pdb: removed %%desc%% placeholder, added
some
missing argument descriptions.
* app/pdb/*_cmds.c
* libgimp/gimpdrawabletransform_pdb.c
* libgimp/gimpfloatingsel_pdb.c
* libgimp/gimpgradient_pdb.c
* libgimp/gimppainttools_pdb.c: regenerated.
* app/core/Makefile.am
* app/core/gimpparamspecs-desc.[ch] (gimp_param_spec_get_desc):
new function that creates a parameter description for the PDB.
* app/pdb/gimppdb-query.c
* app/pdb/procedural_db_cmds.c: use the new function to create
the
descriptions on the fly.
2005-08-03 Michael Natterer <mitch@gimp.org>
Changed naming scheme for PDB procedure names from
random_crap_that_traditionally_has_underscores to
enforced-canonical-identifiers. I'm pretty sure some things are
broken after this commit. More changes to come...
* libgimpbase/gimpbase.def
* libgimpbase/gimputils.[ch]: added gimp_canonicalize_identifier().
* app/pdb/procedural_db.[ch] (struct ProcRecord): added
"gchar *original_name" to keep a procedure's original name as
reigstered by plug-ins (compat cruft).
(procedural_db_init_procs): canonicalized list of deprecated
procedures.
* app/plug-in/plug-in-proc-def.c (plug_in_proc_def_free): free
original_name.
* app/plug-in/plug-in-message.c: canonicalize procedure names
which are received over the wire.
* app/plug-in/plug-in-rc.c: serialize the original_name and create
the canonicalized name on-the-fly when deserializing.
* app/plug-in/plug-in-run.c: pass the original_name to plug-ins
when running them because they strcmp() the passed procedure name.
* app/plug-in/plug-ins.c (plug_ins_add_to_db): pass
canonical procedure names to procedural_db_execute().
(plug_ins_file_proc_compare): special-case "gimp-xcf", not "gimp_xcf".
* app/xcf/xcf.c: changed static XCF procedures accordingly.
* tools/pdbgen/app.pl
* tools/pdbgen/lib.pl: do some trivial substitutions to generate
canonicalized names in app/, and C identifiers with underscores in
libgimp/.
* tools/pdbgen/pdb/brushes.pdb
* tools/pdbgen/pdb/fileops.pdb
* tools/pdbgen/pdb/gradients.pdb
* tools/pdbgen/pdb/image.pdb
* tools/pdbgen/pdb/palettes.pdb
* tools/pdbgen/pdb/patterns.pdb
* tools/pdbgen/pdb/plug_in.pdb
* tools/pdbgen/pdb/procedural_db.pdb
* tools/pdbgen/pdb/text_tool.pdb
* tools/pdbgen/pdb/transform_tools.pdb: canonicaloized procedure
names in calls to std_pdb_deprecated() and in procedure names in
generated C code.
* app/pdb/*_cmds.c
* libgimp/*_pdb.c: regenerated.
Jehan