GNOME Bugzilla – Bug 129598
Vectors need a PDB interface for multiple components
Last modified: 2006-11-20 15:36:37 UTC
The new vectors infrastructure is more flexible than the old one. Esp. it enables the user to have multiple open strokes in a single vectors object. At least this possibility should be exposed to the API. I.e. a vectors object should be able to extended with a single - open or closed - stroke. In the core we do have nice functions to extend an existing stroke, but since this functionality has to assign IDs to the individual strokes, this probably won't make it in 2.0. I want to add something like gimp_vectors_add_bezier_stroke (path_id, num_points, coordinates) and it might return an integer, that should be ignored now, but could be interpreted as a stroke id when extending the API later. I want to try to implement this in 2003... :-)
We'd like to get the pre-release out before the end of this year. What is a reasonable time-frame for this addition to the PDB?
Hi, I'd prefer to see this added for 2.2. It's not something that's essential for a 2.0, and if there are problems with it, it might delay a 2.0. I vote for a bump (changing the milestone appropriately). Dave.
Sven convinced me that it is not a good idea to urgently hack together an API. It should be tested in the real world so that we don't get another broken API that we have to work around. So for me it is OK, to set the target Milestone to 2.2.
Since we still don't have such an API, this will have to wait for the next development cycle.
I suggest that we somehow export the API we introduced internally for the SVG parser. In the long run, the SVG path parser could then even become a plug-in. The API we use internally is "documented" in http://developer.gimp.org/api/2.0/app/GimpBezierStroke.html I suggest we make available the functions move_to, line_to, arc_to, cubic_to, conic_to and ellipse (plus perhaps some other simple shapes). The tricky part is how to represent strokes. Is there a global stroke id-space or one that is local to a vectors object?
A way to manipulate each stroke as an independent object is what is lacking most. Today there is gimp-path-get/set-points - a script have to read the whole path in, perform all calculations if changes are going to be made, including bezier control point calculations, and set all points back. So I'd say a gimp-path-get-components is needed, and such things as: gimp-path-component-delete (path-name, component-number) gimp-path-component-new (path-name, component-position) gimp-path-component-insert-point-at (path-name, component, position, point-x, point-y, cp-1-x, cp-1-y, cp-2-x, cp-2-y) and a delete point counterpart, Transform functions, possibly working in point-ranges, or component-ranges like gimp-path-components-rotate (path-name, start_component, end_component, angle) Most important: a componet-based, _sane_ version of gimp-path-get-point-at-dist possibly just a gimp-path-component-get-point-at-dist (path-name, component, distance), with 0<= distance < 1 or better - coupled with a gimp-path-component-get-lenght, and the above function would accept the distance paramenters in pixels (or image units). This owuld make it easier for scripts to implement path-stroking effects. As for the functions Sven suggested: most could append their points to a component (open component), start a new componet on move_to, and, ther eis also dthe need for a "close_component" function if those are ever implemented.
*** Bug 304381 has been marked as a duplicate of this bug. ***
I have started working on the PDB API. You can now add/delete vector objects and add/delete strokes of it. the Undo System does not work at all yet. Please test the stuff in current CVS, read the Changelog to spot the new functions (or search for "vectors" in the PDB browser).
Raising priority to Urgent since, with 2.4 approaching, this functionality needs to be tested and stabilized -- or, if it cannot be stabilized, backed out.
Simon, how much is missing to mark this as FIXED? Is the current state in CVS OK for a release or should we better back some changes out and implement a full vectors API for 2.6?
I'd like to see this in 2.4. Missing PDB-wrappers are: gimp_vectors_new_from_file() gimp_vectors_new_from_string() These functions basically will boil down to gimp_vectors_import (). That might need some tweaking to be able to return the newly created vectors (if we don't merge the paths in an SVG - do we return a list or an array of IDs here then?). gimp_vectors_stroke_get_points () gimp_vectors_stroke_set_points () Not sure how important these are. I just realized that _set_points creates a new vectors object always, it might make a lot of sense to replace it with gimp_vectors_stroke_new (vectors_obj, type, coords, closed), where type would be an enum of the available stroke types (currently only BezierStrokes). Not that urgent, since we have other constructors for Bezier Strokes. For _get_points we need a new accessor for the points in the class, but that is not that hard, except that I need to get off my butt. There are some other missing wrappers, but these can easily created from their _path_ equivalents. Most urgently the Undo does not work if you invoke that stuff from the PDB. That right now is a stumbling block for me, especially since it might need work on the path tool as well. I'd appreciate somebody giving me a push in the right direction here. I believe we can get this in shape for 2.4, but I need help on that Undo issue.
I am attaching a patch that provides "undo" for all of the things in vectors.pdb that need it. I did it by using gimp_image_undo_push_vectors_mod() in all but one case. It might be possible to make it consume less memory by adding new functions to gimpimage-undo-push.c, but since vectors objects are not usually huge, it doesn't seem urgent to me. I have tested some but not all of this stuff.
Created attachment 71470 [details] [review] patch for tools/pdbgen/pdb/vectors.pdb
Another thing missing from the vectors PDB api is the ability to get control points/ stroke information in general. (tell me if this doesn't belong here) It's possible to get the end and start points of a stroke by startx, starty, slope, valid = pdb.gimp_vectors_stroke_get_point_at_dist(vectors, stroke, 0.0, precision) length = pdb.gimp_vectors_stroke_get_length(vectors, stroke) endx, endy, slope, valid = pdb.gimp_vectors_stroke_get_point_at_dist(vectors, stroke, length, precision) But this is hackish and I don't think that going to such lengths should be required. It's probably also possible to infer control points from a sampled curve generated by pdb.gimp_vectors_stroke_interpolate, but that would be even more hackish and undesirable. IMO a workable interface would look like: pdb.gimp_vectors_get_strokes_info and pdb.gimp_vectors_get_stroke_info returning a FLOATARRAY with elements [controlpoint1x,y, anchorx,y, controlpoint2x,y] I might have a go at that, if someone can verify it actually is the right thing to do.
in other words, the gimp-vectors-* api lacks the functionality one gets with gimp-path-get-points -- which should get deprecated once there is a gimp-vectros equivalent that is stroke aware.
Added an implementation for gimp-vectors-stroke-get-points to CVS. Please test. This should also address what David was missing. Keeping this bug open for the gimp_vectors_new_from_* functions. 2006-10-24 Simon Budig <simon@gimp.org> * app/vectors/Makefile.am * app/vectors/vectors-enums.h * app/vectors/vectors-types.h: added new file for the vectors enums, adjusted Makefile.am for the generation of vectors-enums.c * tools/pdbgen/Makefile.am * tools/pdbgen/pdb/vectors.pdb: Added implementation for gimp-vectors-stroke-get-points which returns the control points for the stroke. Renamed gimp-vectors-stroke-remove to gimp-vectors-remove-stroke. ATTENTION: this breaks scripts using this function, a simple name change is enough to make it work again. Also please note that yosh reordered the return values of gimp-vectors-stroke-interpolate, so your scripts need adjustment there as well. * tools/pdbgen/pdb/paths.pdb: deprecate gimp-path-get-points. Yay! * libgimp/gimp.def: added new symbol * plug-ins/pygimp/pygimp-vectors.c: reflect name change of gimp_vectors_remove_stroke (). * app/vectors/vectors-enums.c * app/pdb/internal_procs.c * app/pdb/paths_cmds.c * app/pdb/vectors_cmds.c * devel-docs/libgimp/tmpl/gimpvectors.sgml * libgimp/gimpenums.c.tail * libgimp/gimpenums.h * libgimp/gimppaths_pdb.[ch] * libgimp/gimpvectors_pdb.[ch] * tools/pdbgen/enums.pl: regenerated.
I for now consider the new vectors API complete, if you miss any functions please file a new bug for these. Closing as FIXED. 2006-10-26 Simon Budig <simon@gimp.org> * app/vectors/Makefile.am * app/vectors/gimpstroke.h * app/vectors/gimpstroke-new.c: new factory for GimpStrokes. * tools/pdbgen/pdb/vectors.pdb: use it for gimp_vectors_stroke_new_from_points() * libgimp/gimp.def: added new symbol * tools/pdbgen/pdb/paths.pdb: deprecated completely! Yay! * app/pdb/internal_procs.c * app/pdb/paths_cmds.c * app/pdb/vectors_cmds.c * libgimp/gimppaths_pdb.[ch] * libgimp/gimpvectors_pdb.[ch]: regenerated. 2006-10-26 Simon Budig <simon@gimp.org> * tools/pdbgen/pdb/edit.pdb: added gimp_edit_stroke_vectors () * tools/pdbgen/pdb/paths.pdb: deprecated gimp_path_stroke_current () * libgimp/gimp.def: updated. * app/pdb/edit_cmds.c * app/pdb/internal_procs.c * app/pdb/paths_cmds.c * libgimp/gimpedit_pdb.[ch] * libgimp/gimppaths_pdb.[ch]: regenerated. 2006-10-25 Simon Budig <simon@gimp.org> * app/vectors/vectors-enums.h: Oops. Need to specify both pdb-skip and skip. * libgimp/gimp.def * libgimpconfig/gimpconfig.def * libgimpmath/gimpmath.def * libgimpthumb/gimpthumb.def * libgimpwidgets/gimpwidgets.def: .def-file maintenance. Hope my changes are correct... With the help from nm .libs/libgimpfoo-2.0.so |\ sed -ne "s/.* T \([a-zA-Z0-9][a-zA-Z0-9_]*\)/\t\1/p" |\ (echo EXPORTS ; LC_ALL=C sort ) * libgimpwidgets/gimppageselector.c: marked stretch_frame_image() as static. * libgimp/gimpenums.c.tail * libgimp/gimpenums.h * tools/pdbgen/enums.pl: regenerated. 2006-10-25 Simon Budig <simon@gimp.org> * app/vectors/gimpvectors-import.[ch]: extended gimp_vectors_import() and friends with a parameter for returning the newly generated vectors. * app/actions/edit-commands.c * app/actions/vectors-commands.c * app/display/gimpdisplayshell-dnd.c * app/widgets/gimpvectorstreeview.c: Changed accordingly. * app/vectors/vectors-enums.h: moved the GimpVectorsStrokeType to... * libgimpbase/gimpbaseenums.h: ... this file. * app/vectors/Makefile.am: Changed accordingly * app/vectors/vectors-enums.c: removed accordingly. * tools/pdbgen/pdb/vectors.pdb: new functions gimp_vectors_new_from_file() and gimp_vectors_new_from_string(). * tools/pdbgen/pdb/paths.pdb: deprecated the previous functions. * libgimpbase/gimpbase.def * libgimp/gimp.def: added new symbols * app/pdb/internal_procs.c * app/pdb/paths_cmds.c * app/pdb/vectors_cmds.c * app/vectors/vectors-enums.c * libgimp/gimpenums.h * tools/pdbgen/enums.pl * libgimp/gimppaths_pdb.[ch] * libgimp/gimpvectors_pdb.[ch] * libgimpbase/gimpbaseenums.c
The new API is really nice :) bug #347677 (pdb interface for stroking vectors) was filed before this bug was closed; it is still valid AFAIK (my explorations suggest there is still no way to do that other than using the GIMP GUI. gimp-edit-stroke-vectors accepts an ID rather than a Vectors object. Is that correct behaviour or an oversight?
There is no vectors object on the libgimp side, just as there is no image, layer or channel object.
Probably he means that pygimp wasn't translating PDB_VECTORS into pygimp Vectors objects. This is fixed as of my recent commit.
Still [were] missing gimp_vectors_stroke_rotate, gimp_vectors_stroke_flip , and since we are at it, gimp_vector_stroke_flip_free I am attaching the patch for these.
Created attachment 75559 [details] [review] Patch to add missing vector stroke transforms Patch includes pygimp vector_stroke object methods.
Indeed these look useful too. And there is also the issue with undo (the other patch still attached to this bug). Joao, would you upload a new patch with my changes to the flip matrix function merged?
Created attachment 76059 [details] [review] Updated patch using fixed matrix-transform-flip-free call
Fixed in CVS, thanks for the patch. 2006-11-20 Simon Budig <simon@gimp.org> * app/vectors/gimpstroke.[ch] * tools/pdbgen/pdb/vectors.pdb * plug-ins/pygimp/pygimp-vectors.c: Applied patch from Joao S. O. Bueno Calligaris that adds some missing transformations to the PDB-API for strokes. Fixes bug #129598. * app/pdb/internal_procs.c * app/pdb/vectors_cmds.c * libgimp/gimpvectors_pdb.[ch]: regenerated.