SoC Progress
This is basically a report on my progress, as posted to the inkscape-devel list this morning, but with lots of spelling and grammer corrections!
I have created a connector tool context, that will be used for interacting with connectors. Connectors will just be paths in SVG, and will be marked up as a connector, in much the same way as a star. I felt a separate context was the best approach since this won’t change the behaviour of any existing tools. This is probably best while the tool matures, but also makes sense since there will likely be different classes of users, some interested, some not interested in the diagramming features of Inkscape.
The tool was based on the pen tool simply because this creates paths. I’ve found the further I’ve gone into this that extending the DrawContext, just as the pen tool does, may not have been the best approach, since I haven’t really been able to make use of much of it’s code, though this was always attempted first. I’ll likely pull out the DrawContext dependency later, though this doesn’t hurt for now.
The tool uses center connection points. Arbitrary connection points, placable by the user would be desirable too, but I’ve scoped this initial version as just center points, and we can talk about interfaces for other types when there is an initial version for people to see and comment on.
The tool shows these connection points, using entry events from the context’s item_handler, and doesn’t hide them until they are showed for another shape. The item was to save the context having to display all of these when it was switched into, and also saving the user from selecting both shapes they wanted to connect before drawing the connector.
If you move the mouse really quickly into an unfilled shape the connection point isn’t displayed. I don’t think this is as big a problem as it sounds. I wonder how many diagrams would use completely unfilled shapes. Also, I’m using the standard Inkscape shape selection mechanism, so this is only as much of a problem as only being able to select unfilled shapes with the mouse by clicking exactly on their stroke. FWIW, it works fine for shapes with completely transparent fills. Is there any real difference?
It’s funny really, I chose to use this method since it seemed like the simplest to quickly create a connector context for creating and modifying connectors so I could start looking at desired behaviours from the tools for more complex cases. It’s turned out to present many small problems of it’s own.
I wanted users to be able to drag from one connection point to another, or click on one, then move the mouse (with a visible connector being drawn) then click on a second connection point to create a connector. (They can also just do this on the canvas, creating an unattached connector.) Turns out for the click and drag approach, where the user is moving the mouse with the left button depressed, no entry events are passed to the item_handler. I don’t actually understand why this is so, and I’ve looked pretty deep through the events code. (It’s not due to a knot being dragged by the mouse cursor, as this was my first thought too.)
This code is very close to working. But I still have to do the stuff for allowing users to reroute connectors within the connector context, i.e. moving an existing connectors end-point to attach to a new shape.
The interface for my routing library code has also been cleaned up further, and put in a namespace of it’s own. There is a very small amount of logic that needs to be moved from my own diagram editor into the library, but this is literally a couple of functions that wrap other function calls and this is trivial.
In general, I’ve found work on Inkscape to take a lot longer than expected. This is mostly the steep learning curve of figuring out the Inkscape internals. I guess since I am working at a canvas manipulation level, rather than on some fairly self-contained sub-section of the code, I need to look at more code to work on things. I’ve found it to take a long time to figure out *how* to do things, but then the actual code to do it is usually simple or at least not too complex. I’m also finding it interesting and fun too!
In terms of some of the other aims of SoC, I’ve kind of become the official Mac person for Inkscape, and have taken part in many of the community aspects of the project. Since I’ve been using a Mac as my development environment I have also been working on OSX packaging for the release and associated bugs and fixes. I’ve therefore been active on the mailing list, working with the bug tracker, and answering questions on #inkscape, etc.
Summer of Code is turning out to be quite a valuable experience, and I’m really enjoying being a member of the Inkscape development community.