Hi, I'm moving on refactoring the connectors code. I just changed the toolbar a little bit so every connector type has its own button. During refactoring, two questions arised: 1. What does "Ege" as in "EgeAdjustmentAction" mean? 2. What semantics do we want concerning which objects are to be avoided by a connector?
A little elaboration on the second question: Currently, Inkscape uses libavoid to route object-avoiding connectors. All object which should be avoided by the router are added an "inkscape:connector-avoid" attribute. This does not, e.g., allow an object to be avoided by certain connectors and ignored by others. I can currently see three obvious solutions to that problem: * Avoid objects based on group/layer membership. E.g. avoid any objects on the same top-level layer but ignore others. * Avoid objects based on a "tag". This is not unlike the current approach, but I would really use a class instead of an own attribute for this to be easily interoperable with other implementations of this, especially a potential javascript router as discussed with Doug Schepers from w3c, who is currently working on a SVG connectors spec. Personally, I favor the second solution since I think it is less hacky and more flexible. I think it would be a sane choice to have connectors avoid objects by default and to explicitely mark objects to be ignored while routing. If you wanted a connector ignoring any objects you could just use the non-libavoid routing types I am just adding. * Any combination of the above
If you have any thoughts on this, please share them with me ;)
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.
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.
Best regards, Sebastian
[0] http://dev.w3.org/SVG/modules/connector/SVGConnector.html#PointElement