Hi Krzysztof!
If you want to work with multiple paths, [...]
Don't I need to, in order for it to work in full generality? Also, I didn't see how I would be able to access only a single path from within the node tool context. From a brief look, _multipath seemed to be the right way to start for obtaining the path data. Or should I go via _shape_editors instead?
[...] the simplest way might be to add the necessary code to MultiPathManipulator and/or PathManipulator, but that depends on what you want to do - writing public methods to access the node-based representation of a path might be better. If you supply more detail about what you want to do, I can offer some suggestions.
I was having a look at this mockup: http://garoth.com/?p=63 Not sure if it can/should be implemented in exactly the way described, or even whether I will have time to do it anytime soon, but I was going to have a play in order to get a feeling for it.
To begin with, all I was trying to do was to traverse the nodes of the path(s) being edited and detect sequences of adjacent ones that are currently selected (so that later on additional nodes could be inserted in the path at appropriate locations). Any suggestions how that can best be done? It feels like it might be worth exposing the data of the paths being edited in MultiPathManipulator, but I wasn't sure whether that was intentionally avoided by design for some reason.
Thanks for your help! Max
P.S.: While browsing the code I noticed that the class ShapeEditorsCollective is only in shape-editor.h and nowhere else (and isn't even defined anywhere). Is this a remnant of the old node tool that can be scrapped?