Today I started work on making an IDE and/or rewriting Turtle graphics. I started with a few spike tests. The first was to see how to go about using the rsvg library to render SVG graphics. So far I'm disappointed (or, rather my disappointment is renewed), it does seem you can't get at the DOM representation, nor can you register for events on the various elements (i.e. do hit-testing to see what element in the SVG received a mouse event). In other words, to render in SVG you have to write a textual SVG file/string and the structures inside the SVG just disappear (it may as well be a bitmap, modulo scaling).

Okay, so probably go for straight GTK rendering to start, I started with the current Turtle graphics code. Refactored into a non-GUI-specific Turtle class that encapsulates the state and drawing code (and includes comments and documentation strings) and a back-end that does the GUI-specific drawing.

Of course, this being my first real GTK project, I'm somewhat floundering there (I normally use wxPython, PyGame or GLUT/GL, I seem to have messed up in isolating the "canvas" part of the Turtle graphics). Haven't found a portable FloatCanvas-like widget for GTK yet, I'd like something that allows us to draw to unlimited extents, but clips the actual drawing to the displayed area and allows for scrolling, zooming, etceteras. Haven't spent that long looking, though.

The new design should allow for children's code that looks like this:

TURN = 5
for i in range( 360/(TURN*2) ):
    t.forward( 20 )
    t.left( TURN )
    t.arc( TURN, 5 )

where "t" is simply a Turtle object instantiated outside of the loop and provided in the execution name space for the code. The Turtle's queue of commands will then be used by the GUI back-end to draw (and/or animate) the commands. Should also allow for multiple simultaneous turtles should we decide to support that (no global state storage).

The idea is that the "Turtle Graphics" view of the IDE will automatically provide the turtle object that you can use to render, while a different view (possibly packaged as a different Activity) simply won't have the turtle object provided, as a result it won't provide a canvas onto which to draw (unless you define one yourself).

We'll probably want to use the sys.settrace operation to allow for break-point and debug operation, but the animation can be done simply by slicing the queue of graphics commands and rendering only the sub-set on a given iteration of the animation. It's the traditional debug-view and breakpointing that want the settrace stuff (though an animated "slow" debug would be pretty useful and cool).

I've also re-written the arc-drawing routine using step-based line rendering, so that kids looking at the code can see what's being done more readily than using a canvas-level primitive. Remembering back, one of the first things I ever programmed (when I was 7 or so) was a little drawing program on the Apple II+ and one of the first lessons from my dad was how to draw an arc (I couldn't figure it out in grade one).

The Turtle code itself is pretty simple, and the renderer only needs to know how to clear the screen and draw lines at this point (when we add things such as rendering text, filled shapes, bitmaps and svg graphics that will change). I've got a basic test-suite for the Turtle code (but not for the GUI renderer, that's well past my GTK mojo).

I'll need to figure out what I'm doing wrong in setting up the GTK context and get the GTK renderer working, then I can start into the really fun stuff (parsing, code generation and the visual representations of the code).

After that I'll have to read through some of the other IDE's source-code to see how they are handling running code, I would *like* to get the running code out of the IDE's process, but I think that would require an instrumented interpreter or some pretty icky hacking.

Also thinking about how to handle docstrings and localised variable/function names. I'm considering (with a great deal of trepidation) the possibility of having a tag at the start of the files that marks them as turtle-code (or even a different extension, or whatever).

With that tag in place, we'd do something nutty like translating utf-8-encoded local names into a 64-character encoding that only includes ascii upper and lower-case names. We'd store the code in the file using the insane format and then present it as localised text in the IDE (that is, you would edit the file as though Python supported unicode identifiers). Python is, IIRC scheduled to grow unicode identifier support at some point, but probably don't want to wait for that.