On 07/30/2013 01:57 AM, Michael Wybrow wrote:
Hi Sebastian,
A couple of quick thoughts:
- You won't get the behaviour of avoiding specific obstacles with different connectors using libavoid, since it routes connectors using a single visibility graph built from the obstacles for the whole diagram.
Ok, I think that's fine. The only use case I can imagine is something like PCB routing where you could want one visibility graph per layer.
- I think it would be fine to mark objects as obstacles using something other than a property.
- The reason for not avoiding all obstacles by default is that libavoid can be slow -- O(n^2 log n) -- especially if there are a lot of obstacles. You don't want this slowness if you open a file with hundreds or thousands of objects that libavoid tracks as objects by default. That was the reason for the original decision to have the user explicit mark objects as obstacles for routing.
Shouldn't this be in O(n log n)?
I'm now moving on to implement (somewhat minimalistic) "points" as described in [0] so I can then head towards renovating connector-context.cpp. My latest commit to launchpad breaks in an assertion when drawing a connector since it needs these changes. The commit before that should work, though.
These "points" will be placed whenever one places a connector's end, except if one places a connector's end on an existing "point". When drawing a connector, all visible points will be rendered as knots. This enables template-based diagram elements which are just are groups that contain a shape and one or more points for the connector to attach
FWIW, newer versions of libavoid understand and track "connection pins". These are points specified based on a position on shapes. They move if the parent shape is moved and can be specified as the endpoints for connectors. You might want to make of these.
Thanks. This behavior can easily be implemented by putting a few SPPoints into a group with some shape. The new connector code just creates these SPPoints as needed, and handling of object centers/corners/nodes etc. should be done by just snapping their locations to these points.
It could be worth updating the version of libavoid in Inkscape to the latest version found here: https://github.com/mjwybrow/adaptagrams The only real work there would be how you find and track attached objects once using connection pins.
By moving to SPPoints this is actually pretty non-problematic since they will just move with the groups containing them.
I think there was a previous dev who started doing the connection pin work in Inkscape but I'm not sure what happened to that. It doesn't seem to be on the trunk.
I will remove any logic from connector-context responsible for handling anything but two endpoints (if you want to draw a connector with multiple "stops", just chain together multiple connectors) and remove the "snap connector end point to connector's intersection with destination shape outline"-logic since I do not think this is too useful.
Do you mean the functionality that adjusts the endpoint of a connector to stop at the intersection with the destination shape? If so, the reason for this is that the arrowhead is drawn at the end of the connector and people frequently want this to coincide with the edge of the shape.
I removed that because it would have been even more work porting and because with the addition of SPPoints it is not really necessary anymore (I am not totally against re-adding it, though).
Best regards, Sebastian
[1] http://dev.w3.org/SVG/modules/connector/SVGConnector.html