I found I was still able to connect by doing the following:

1. In Finder, go to the “Go” menu and then to “Connect to Server…”
2. Enter the following in the Server Address field:
   vnc://macname.local:5900/
   or with IP address:
   vnc://192.168.0.1:5900/

ld: library not found for -lX11

After a fair amount of searching, I couldn’t find a solution but stumbled on this thread talking about the system_x11 variants being removed from Macports.

Basically, the problem was that it is expected that all ports now use the X11 library available in Macports.  Of course, this will cause problems if you already have all these X11 ports installed with +system_x11 — effectively just empty ports.

The solution was to run the following commands to find, deactivate and then reinstall all ports that were installed with +system_x11 variants:

$ xports=`port installed | grep system_x11 | \
          cut -f3 -d' ' | xargs`
$ sudo port -v deactivate $xports
$ sudo port -v clean $xports
$ sudo port -v install $xports

You can then remove the deactivated system_x11 versions via:

$ sudo port -v uninstall `port installed | \
          grep system_x11 | cut -f3-4 -d' ' | xargs`

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 some 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…