User Verification Required for Sign-In, or
Can’t Sign In. See Preferences: Fetch -2

After much rooting around in preferences files and keychain access I determined that the cause of the problem is that Google Notifier needs access to a https keychain item for the proxy we use here. This didn’t exist for my colleague as the keychain item seems to be created by Safari when visiting a https site for the first time. If you instead use Camino then it never seems to create a https keychain item for the proxy and seems to just use the http keychain for the same proxy for https sites.

Probably Google Notifier should prompt for the https proxy username and password if it can’t find an existing keychain item.

The fix is to open Safari, visit a https site (such as https://www.google.com), enter your login details for the proxy and tell keychain to remember them. Then, restart Google Notifier, and it should ask for access to this keychain item. This has sucessfully fixed this problem for me on three separate Macs.

Autorouting polyline connectors are in CVS and work well. However you manipulate them, they will avoid objects marked as ‘avoided’. Objects can be marked as ‘avoided’ or ‘ignored’ via the connector context toolbar buttons. Tricky to explain, but easy to see and understand… just have to play with it.

The following wiki page has instructions and further discussion:
http://wiki.inkscape.org/cgi-bin/wiki.pl?UsingTheConnectorTool

There are a couple of obvious problems:

1. Connectors are drawn to object’s bounding boxes, rather than edges. I have a couple of ideas and some code to address this, so it shouldn’t be too long till this is in the codebase.
2. Bounding boxes are used for the avoidance code, i.e., lines will route around a diamond as if it was a rectagle. The routing code deals with polygons so it’s just a matter of me or someone else properly implementing the NR::ConvexHull class.

There are plenty of other features I plan to add, some that have been requested by people already. Toolbar marker (arrow head) controls being one of these. See my TODO list on the wiki or in src/connector-context.cpp.

Please have a look at the wiki page, and try out the connectors. Then add to the wiki page with ideas/problems or open bugs/RFEs.

I’ve really enjoyed working on Inkscape the past two months, and as I said in an earlier mail, I feel like this time has got me over the initial hurdle of learning the codebase. I feel much better placed to comfortably contribute in the future. Basically, expect me to become a regular on the mailing list and Jabber.

Also, one of the things I’ve noticed as a result of the Summer of Code time is the real community aspect of the Inkscape project. It’s a really open, welcoming community. I’d heard of students working for other projects who really didn’t have much contact with their mentoring organisation, and were still waiting for accounts for CVS etc at the end of August. With Inkscape on the other hand, developers and users were always helpful and friendly. Just wanted to thank all the Inkscapers for that!

Click and drag anywhere to create a connector. If you start or finish over a highlighted connection point, then the connector will be attached to that shape. Dragging the endpoint of any existing connector will alter its endpoint, and attach to a shape if dropped on a connection point.

It is usable, but there are some issues. Partly this is because I originally chose to build it on top of the DrawContext and having that underneath is now preventing the exact interaction I want. I’ve done most of the work of removing this dependency but will finish it later. The current interaction doesn’t use the standard selection mechanism. One of the choices I made was that I didn’t want the user to have to select a shape to show its connection point, select another for the same reason, and then have to click or drag between the two shapes to draw the actual connector. For this reason the connection points for shapes are shown when the mouse is moved over them. Play with this for a while and I think you’ll find it quite natural.

At the moment though, due to the draw context stuff, the same behaviour is true for the actual connectors — they are ’selected’ by moving the mouse over them. This is bad since the connector focus jumps around as you move your mouse over different connectors. The true selection mechanismis ignored and the selection cleared when the context is entered. Also bad.

The planned solution is to use the standard selection mechanism and show endpoints for the first selected connector, much like the node tool. This means the same selection will be maintained swapping into and out of the connector context. Also, if you’ve just drawn a connector and want to change its stroke style, another connector isn’t going to be selected on your way to the dialog, as Peter pointed out to me today. The mouseover displays connection point behaviour will be kept for shapes but will be completely independant of the selection.

Anyway, I thought it important to commit this now, even though I’d love to perfect the interface a little more before showing it off. It’s already suffered a fair amount of slippage due to many little unforeseen issues, and my complete ignorance for the complexity of the Inkscape internals. Plus, I feel its important to focus on the integration of the autorouting code, the other main ‘goal’ of my Summer of Code application.

Comments and bug reports welcome!

(The src/connector-context.cpp file contains my rough todo list, e.g., I’ve done some work towards drawing connectors to object edges rather than bounding boxes, but this isn’t there yet.)

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.

I opened the lid on Thursday morning ready to start work, expecting to be greeted by it’s warm glow. Nothing. I pressed the left arrow key (this usually wakes it up). Not this morning. It was working hard last night. Sure, but this is ridiculous. It got a few good hours of rest! I pressed the power button. Nothing. Ah, maybe the battery had drained over night? Hadn’t suspended properly, maybe? Plugged in the power cable. Pressed the power button. It starts. Sort of. There are three tones, then the clasp light flashes four times. Nothing more.

I drove to Uni and spent some time seeing if anyone had a firewire cable to see if I could start it in target mode to get a copy of my Inkscape SoC workspace off it. Everything on there is backed up, but the copy of the Inkscape stuff was a little out of date. Anyway, noone had one so of I went to the Apple service people. I told them I really wanted som of the data off there if possible. He suggested they try replacing the RAM first. Did this, the computer started fine. Problem fixed.

I drove back to Uni and worked for the rest of the afternoon hours. Drove home. Opened the lid, made a small change to some code to try something else. dropped back to a shell, typed “make”, and the computer froze. Rebooted it and found three beeps and the four flashes again. So I guess the problem is the logic board after all. *sigh*

The computer is back with the Apple service people. I’ll probably get it back in a week and a half. I got my workspace off it though, and it looks like my Debian install is finished now, so back to it…

Also, it seems like there will be a Software Exhibition, where you can show of cool graph drawing code. So I should be able to show off not only Dunnart, my research test-bed diagram editor, but also the same capabilities integrated into Inkscape.

Very nice indeed!

I feel like there has been a lot of paperwork in the last couple of weeks. Some non-US students (like myself) have started to call this Google thing the “Summer of Tax Code” because there has been so much confusion and discussion over taxation issues. It’s ironic how hard it is to give away money. Along with this mound of stuff to organise (most of it is done) I’ve just had to organise PhD progress reports and just now paperwork for conference travel (more in the next post). I think it’s taking me six forms to get to this conference, and that’s before I look at airfares, or conference registration…

Inkscape hacking is much more fun!

For SoC I am doing two things. Firstly, cleaning up and releasing as a LGPL library some code I have written to do incremental object-avoiding connector routing. The cleaning up and interface fixes (from where it was originally tied to my research code) is mostly done. I’ll probably create a Sourceforge project for the library very shortly. I’m thinking I’ll call it libavoid. The code will be added (and probably worked on) within the Inkscape codebase, since we definitely don’t want to add something so new as a dependency. It’ll also have it’s own CVS repository on Sorceforge since this was part of my proposal and it’s been written with the intention that othe software like Dia might want to make use of it.

The second part of my SoC stuff is adding connector capablities to Inkscape (and integrating with the library code). At the moment I have added a new context to Inkscape where connectors can be drawn and interacted with. I’m working on the code for creating connectors and changing their connections. My plan is to have the ability to create new basic straight connectors that follow shapes, as well as an interfact to detach/reconnect them to different objects for the time of the release when this stuff can be added to CVS. Then we can discuss some of the behaviour specifics for connectors and their GUI interface.

The code for updating connectors as a result of shapes moving is already in the codebase and was written some time ago by Peter Moulder, though there was never an interface created for working with them. There seem to be several issues (i.e., bugs) with this at present, so that wikl have to be looked at too.

I’ve found it quite time consuming working out how to do things at the canvas level within Inkscape. Its not that it’s been frustrating, it hasn’t, it just takes a while to figure things out when you’re unfamiliar with the codebase, and you’re not working on a surface feature that allows you to ignore large sections of code. Actually, once I work out the correct way to do things it often turns out that the solution is quite elegant, i.e., it’s been though that someone would later want to do this thing, or something similar is being done somewhere else in the code, so the framework is there. The new gradient tool handles code has been really useful for lifting ideas from. I get the feeling my work up until now would have been much harder without their example.