Hi Martin,
Good news that your back working on connectors and congrats on the birth of your daughter!
Doug Schepers has been actively working on an SVG connectors specification. He hasn't released a draft yet but maybe we can persuade him to. It would be good if you can look at it and comment on it.
Our implementation of connectors should be as compatible as possible with the draft (but in the Inkscape namespace to avoid a repeat of the flowed text debacle). As I understand it, the specification will include "anchor" points on objects to define where connectors attach. The points will be located in a coordinate system given by the bounding box of the object (prior to any transformations). Optionally, a path can be given to connect anchor points. If a path is not given, a very simple algorithm will be specified to determine how the connecting path will be drawn. More complex path layout will be left to the content creator (e.g. Inkscape).
As I've commented before, symbols and connectors are natural to use together. The new Symbols Dialog would be more useful if symbols included connector anchor points.
Tav
On Sun, 2012-12-02 at 23:57 -0500, Martin Owens wrote:
Hey Devs,
I've got a plan for getting last year's connector work into use. I've updated the branch to the latest trunk (damn you changes!) so I'd like to get this merged in because it removes 1110 lines and replaces them with 91. So it's a big cleanup of code that was never in use:
https://code.launchpad.net/~doctormo/inkscape/knot-visio
This branch should maintain the same functionality as we currently have, plus a focus on the next steps to improve the functionality. Testing is required and advice for more experienced cpp developers about the use of std::map instead of a more appropriate std::list structure which I'm hoping can be picked up in merge review.
The next steps are the exciting parts. I thought the idea from last year about having a generic point anchor tool was really interesting. So the way the connector work will happen is, it'll simply use other non-connector functionality to achieve everything we want.
The anchor tool would insert a point path, which would be displayed on screen with either an knot-anchor which would just move along with it, or some other visual identifier which would not appear in renders. It would be selectable using the near-detection and then groupable, transformable etc because it's a real point element on the canvas.
The anchor tool would be useful for a few functionalities. For the connector work we would use the point to join connectors together on canvas, as custom points on shapes when grouped with them, act as flexible points where custom paths around objects are required.
This offers the best combination of features while not requiring any custom attributes or elements and doesn't require a exo-canvas def addition (which would suck IMO). It's also groovy because the amount of code will be small and use lots of existing code to achieve what we want.
Best Regards, Martin Owens
Note: Apologies to all the wonderful responses in the thread last year, a week after my daughter was born and I fell of the productive Internet and only now is my time freeing up a bit.
Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel