Hi Krzysztof!

Thanks for the quick reply! What is the correct way to obtain the PathVector? (Or a list of PathVectorS in case multiple paths are being edited?) I presume I need to extract it from _multipath (in the node tool context), but this is a pointer to a MultiPathManipulator, and it looks like the path data in that class is not publicly accessable. Also, is there a canonical way to find out which of the nodes I'm traversing are selected? From what I gather from the code it seems that the path data itself is conceptually separated from UI stuff like selected nodes. Do I need to check for each encountered node whether it occurs in _selected_nodes (e.g. by comparing the position) or is there a better way?

Cheers, Max

2012/1/16 Krzysztof Kosiński <tweenk.pl@...400...>:

You need to get a PathVector and iterate over segments rather than nodes. If you need the types of nodes too, you could reuse the code in ui/tool/path-manipulator.cpp that contains a conversion from the path

• nodestring data to a node-based representation (I think the function

is called _createControlPointsFromGeometry())

Regards, Krzysztof

I've run into similar difficulties in the snapping code, iirc in _snapPaths() in the object snapper. Managed to work around it partly, but not satisfied yet either.

Kind regards, Diederik

"Krzysztof Kosiński" <tweenk.pl@...400...> wrote:

...

Also, is there a canonical way to find out which of the nodes I'm traversing are selected? From what I gather from the code it seems that the path data itself is conceptually separated from UI stuff

like

...

selected nodes. Do I need to check for each encountered node whether it occurs in _selected_nodes (e.g. by comparing the position) or is there a better way?

Use the selected() method (it's inherited from SelectableControlPoint).

On 17-01-12 00:20, Maximilian Albert wrote: ...

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.

Nice :)

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.

My knowledge of path editing code is quite limited, but have you figured out how moving (and/or sculpting) a group of nodes works? If so, what's preventing you from essentially modifying that code to add two nodes at the ends of each "selection segment" (at the very least the sculpting code seems to be aware of such segments).

W dniu 17 stycznia 2012 00:20 użytkownik Maximilian Albert <maximilian.albert@...1439...> napisał:

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?

_shape_editors is for things like gradient manipulators, rectangle editing controls and pattern controls, it has no information about paths.

...

[...] 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.

Looks like this should be part of the node editor. Specifically, this is very similar to how the "insert node" button works, and we could think about modifying the insert node button so that it defaults to this new "extrude" behavior. I imagine that the current behavior of inserting a second node at each selected node is not very useful, while inserting a node at selection boundaries would be very useful.

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.

This extrude functionality would be an integral part of the node editor, so it's best to add a function to PathManipulator, and another one to MultiPathManipulator that just calls the new function on all PathManipulators. (But see above - maybe it's better to modify the 'insert node' function)

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?

It was an attempt by Bulia to have multiple ShapeEditor's active at once. It's not necessary any more, I did it in a different way in InkNodeTool.

Regards, Krzysztof