Cancel: button or link?

At work we're having a bit of a feud over whether the Cancel "action" on a web form should be a link or a button. I can see good arguments in both directions. I end up leaning a little toward the link camp.

Button

• Desktop applications tend to have buttons, not links
• It's less important which standard you pick, than that you pick one.

Link

• Most of the time you want to confirm an action, not cancel it
• An extra choice requires extra thinking. Make that choice easier, not harder, to make correctly.
• A link is visually distinctive compared to a button, so should help the user make the right choice.
• Actions should be buttons, nonactions should be links {citation needed @ that comment - I couldn't find it}
  

My preference is to have a cancel link, if it's possible to maintain a stateless feel on the form. If the user feels like the server is building some state, sie'd feel safer with an explicit forget it action - a button. Otherwise, just offer a link to navigate off the page (subtly hinting that it's safe to do so, by, for example, putting this link next to the confirm button) and be done with it.

I would, however, tip my hat to the button camp: I'd avoid labeling the link as "Cancel". The string "Cancel" is simply too deeply associated with desktop application dialog boxes' cancel button for a link with the same label not to cause an interrupt.

I'm now looking for alternative ways of expressing "Cancel", that don't sound awkward, and are short enough to act as an anchor

A related question is whether OK/Cancel or Cancel/OK is better. But that's an orthogonal issue, not for this post.

REPL in gschem

The existing scheme command entry box in gschem seemed a bit limiting, so I set out to build a proper evaluation environment. Here is the result:

My goal is to be able to evaluate arbitrary expressions and turn the result into a controller of the view: I want to have the main window's object selection to track the cursor in the GtkTreeView result.

Update (2010-07-09): selection tracking now works! Probably with some bugs due to the way objects and their attributes are commingled in the overall object list.

Where expressions evaluate to a lambda, it should be easy enough also to call that lambda when the row representing that lambda gets a double click (signal "activated"). I'm not sure if that's particularly useful for schematic capture, but it would certainly make Frank happy for REPL goodness.

The code for this is available as a git repository at repo.or.cz, in branch "berndj/master-20081019".

Uncoordinated settlers

My FreeCiv client-side AI (not related to [1]) is sending settlers off to found new cities, but they are still a bit uncoordinated. It may be as obvious as in this composite screenshot where two contemporaneously-existing settlers are on paths crossing each other. I've fudged the image a bit to show one settler's path info in purple and the other's in yellow.


My little Turkish empire could save a couple of turns by letting the yellow and the purple settlers switch targets. Time is money! I don't think I'm too far off from being able to do these exchanges. I expect that optimising the routing might be NP-complete (just has that Travelling Salesman "feel"), but I could probably brute-force it as there are unlikely to be more than a handful of settlers active at any one moment.

[1] http://www.cs.northwestern.edu/~forbus/395gai/homework.htm