Have pushed updates that let the turtle's graphics get animated via the GUI. Code doing that is still pretty simple, but it seems to work reasonably well in terms of animating what was done to draw the graphics. Uses the whole command-set (at least, what's been drawn to date) to determine scale/transform, so that the display field remains constant during the animation (changing as it goes is cool, but it could be a bit sickness-inducing).

Next up is making changes to the turtle generate events so that the canvas can automatically animate for "slow code" animations (scripts that sleep for X period and the like). After that it's looking at "debuggable" turtles with a source-code view.

[Update] Okay, after a nap, the slow-code animation/observation now works properly. While the turtle is drawing in a background thread the GUI thread will get updates when the queue of commands changes. The animation code can animate up to the current point, so if you're in the middle of debugging (background code paused) you can still see the sequence of operations for the turtle. Realised while doing all this that at least on Linux we can use DBUS for the client-code's interface to the turtle and run the whole of the user code in a separate process (and a separate Rainbow container, likely).