I think I'm pretty close to a working patch for adding a node on click. Thus far all the difficult code I needed was already in the codebase somewhere. bbyak got me started; cyreve helped me find things (both much more patiently than necessary). I currently have this: on clicking a path I can calculate the segment to break and t along that segment. The segment is represented by the index of the node on the far side of the segment. First node is 0. When I hook up code to add the node to nodepath the new segment ends up in strange places. I think I need help understanding how to work with a nodepath. The patch in its current broken state can be found at http://www.ekips.org/comp/inkscape/inx/nodeadd.diff. I'm sure there are a bunch of C++ problems to clean up and redesigns necessary before it is ready to commit and I'm ready for that but right now I'm just frustrated with not understanding why the nodes go where they do.
Aaron Spike
On Sun, 14 Aug 2005 aaron@...749... wrote:
I think I'm pretty close to a working patch for adding a node on click. Thus far all the difficult code I needed was already in the codebase somewhere. bbyak got me started; cyreve helped me find things (both much more patiently than necessary). I currently have this: on clicking a path I can calculate the segment to break and t along that segment. The segment is represented by the index of the node on the far side of the segment. First node is 0. When I hook up code to add the node to nodepath the new segment ends up in strange places. I think I need help understanding how to work with a nodepath. The patch in its current broken state can be found at http://www.ekips.org/comp/inkscape/inx/nodeadd.diff. I'm sure there are a bunch of C++ problems to clean up and redesigns necessary before it is ready to commit and I'm ready for that but right now I'm just frustrated with not understanding why the nodes go where they do.
Aaron,
I took a look after we spoke on Jabber, but due to different timezones I'll give you my thoughts here. There seem to be a few issues.
Note: I was just looking at paths with only one subpath for my tests.
The nodes list for a Inkscape::NodePath::SubPath contains the nodes for the subpath in the reverse order. So if you click where the X is, and the path has been drawn left-to-right:
o--------o-------X--o------o------o 4 3 2 1 0
You've clicked on the second segment. Unfortunately the nodes are ordered in the list as they are numbered above. To further complicate things, when specifying the path you want to cut you need to give the segment that ends it, so to cut segment one you need to specify the fourth node in the nodes list.
So using the following to work out the argument to pass g_list_nth_data gives you the right node: int ind = n - piece - 1;
Unfortunately, as soon as you add a new node, this no longer works since the node is just added to the end of the nodes list (see the last line of sp_nodepath_node_new).
I get it to work fine for straight line paths using e = sp->first; for (int i = 0; i < piece; ++i) { e = e->n.other; } Instead of what you had: e = (Inkscape::NodePath::Node *)g_list_nth_data(sp->nodes, piece);
This works because it uses the nodes own order which is kept in sync as nodes are added or deleted. The false assumption is that the nodes g_list is ordered.
There are still issues with the positioning when this is used with beziers but this should at least get you over the hurdle you were stuck on.
Cheers, Michael
Michael Wybrow wrote:
There are still issues with the positioning when this is used with beziers but this should at least get you over the hurdle you were stuck on.
Sure enough. Thanks for taking the time to make such a clear explanation. Very much appreciated.
I've submitted the results to the patch tracker for review. http://sourceforge.net/tracker/index.php?func=detail&aid=1264566&gro...
Aaron Spike
participants (2)
-
unknown@example.com
-
Michael Wybrow