I'm sure Michael will correct some of this (e.g. the event stuff below: I haven't looked at the code), but here are some notes.
Michael mentioned on jabber that his laptop was being repaired and that the laptop had ~6 days of work not present on any other computer. Update: he's since briefly recovered his laptop long enough to get the work back, but may be without a laptop for some time.
The status earlier this week (Tuesday?) was that there was a connection tool started, based on the pen tool. Michael has committed an icon for it to CVS, but hasn't committed any other changes yet. The new tool makes a knot appear at the centre of a shape when the pointer enters that shape, so that the user to can draw a line from that knot to another knot at the centre of another shape.
Currently, the tool just draws a line, it doesn't actually attach the line to the shapes.
The implementation of this (connector-context.cpp, I believe) listens for mouse-enter events from our canvas. "Enter" here is based on the hit-detection logic: thus if the mouse is in the middle of an unfilled shape, then the canvas doesn't consider you to be "inside" that shape. Thus, Michael ignores mouse-leave events, resulting knot appearance behaviour something like "sloppy focus" in window managers (fvwm).
I didn't think of the following when I spoke to Michael, but I wonder whether this will result in bugs on slow machines if one enters the shape too quickly to get a mouse-enter event delivered. Is there a corresponding bbox-enter event to get around this? Or maybe there shouldn't be a knot in the centre of the [bbox of the] shape, maybe there should be a different indication of which object will get the attachment.
Another issue with the current choice of event is that these events currently aren't delivered if the button is down: thus one can draw the lines to knots only with xfig-style click at start and at end rather than by dragging from start to end.
I believe Michael's next step is to hook up with the existing connector code I did last year: this gets us basic connector functionality for people to play with.
Michael has also continued to work a little on the path-routing code he has outside of inkscape. I could write more on the plan for making that logic available to inkscape, but let's defer that discussion until we get there.
pjrm.