On Fri, 29 Jul 2005, Peter Moulder wrote:
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.
Yeah, sorry about the delay. I'm only catching up on the mailing list, etc after the computer problems.
This laptop thing is a real pain. I've visited the service people twice in two days, seemingly had the problem fixed by replacement RAM, only to have it die again. The logic board is now being replaced, so I should get it back in a week and a bit. I've just installed Debian on a machine at home and can now build inkscape here at home, and also on my machine at Uni. As Peter mentioned I got a copy of my workspace off it, so nothing lost there, just a waste of time trying to set up a new work environments.
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.
Yes, 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 seperate 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 inital version for people to see and comment on.
As mentioned 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. This works fairly well, except yes,
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.
Yes, 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 problem as it sounds. I wonder how many diagrams would use completly 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 quicly 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.
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 wanted users to be able to drag from one connection point to another, or click on one, then move the mouse (with a visibile 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. I was going to post seperately, but perhaps someone can anwser it here? (It's not due to a knot being dragged by the mouse cursor, as this was my first thought too.)
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.
Ok, 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.
Michael has also continued to work a little on the path-routing code he has outside of inkscape.
Yes, the interface for this has been cleaned up, 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 answer to Bryce's original questions, I should be able to commit the connector context functionality to CVS this week.
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 enjoying being a member of the Inkscape development community.
Cheers, Michael