(There's an elemental set for you. To break ground, to break wind, one's water breaking, a firebreak... four entirely different meanings. Not even opposites. What was I just talking about?)
A folder of code samples and algebraic scribbles, a brand-new 333 MHz Powerbook G3 with Linux installed; everything I needed to start hacking.
Actually, I didn't have the folder. Couldn't find any empty folders anywhere. It was just a stack of loose papers. Oh well.
I always start with some part of the problem that will do something. I hate diving straight into a pile of infrastructure that will just sit there when I'm finished with it. Got to start racking up the motivation right away.
So I started working on the spline layout tool. It needed a name, of course... layout... "lay"... an easy choice, then. It would be Zarf's Layout Tool, or LayZ for short.
LayZ was the only tool I planned to write that needed a graphical interface. (Everything else would operate on numerical data, transforming arrays of numbers into different numbers, and eventually into PostScript.) The X window system is the most awful GUI to write interfaces for, except for all the others, but of course I had old X code lying around. I pulled out the source for
XZip,
my first X text-adventure interpreter. Easy enough to rip out all the drawing code and the game engine, leaving a simple framework which created and managed an X window.
Oh, the modularization. This seems an obvious point, but it's worth mentioning. The LayZ tool would handle only layout. A pure drawing program; no computation at all. After all, it cost nothing to have the computation tools load in a spline-skeleton file from disk. I would have to write the skeleton loading and saving code in any case, for LayZ; it could be shared.
Speaking of that, the next step was defining those skeleton data structures in memory. (There was no need for loading and saving just yet.) Nothing very complicated there. A spline is a list of points, each with two control vectors hanging off of it. I wanted a few other item types as well -- certainly circles, and maybe more to be defined later.
A bit of unavoidable infrastructure, then, to start with. The creators and destructors for a figure (a complete skeleton file), an item within the figure, and a point within the item. Never go anywhere without your creators and destructors.
(Another note: I use C. I'm comfortable in C, I know the language, it does what I want. For simple projects like this, it's as easy to maintain object orientation in C as in other "OO" languages. I don't know C++; nobody does, except Stroustrop, and I'm not betting about him. I'm fond of Java, but I don't know the GUI toolkit well enough to whip out quick hacks in it. I don't know the GUI toolkits in any other languages, either. That leaves C. I don't have a problem with this. Do you?)
Then I wrote code to check for a mouse click, track the drag, and -- on release -- create a two-point spline. Well, a line segment, since the control vectors defaulted to zero and there was no way to change them.
Being clever (as I thought at the time), I built quite a general program structure for handling mouse commands. A set of function pointers, one for mouse-down, one for drag, one for mouse-up. (And one to clean up after interruptions. Details, details.) Set the state of these pointers, and you can change what the next mouse action will do.
I still hoped, at that point, that LayZ would be a generally useful tool. Laying out splines is not unhelpful. (I once started writing an X font editor, and scalable fonts are collections of curves too. Maybe LayZ could be adapted later to serve that purpose.)
But, even at that point, I was taking shortcuts. A full drawing program is a tremendous pain in the ass. Keeping track of what to draw and what to redraw, what's changed -- not to mention selections and highlights -- I've done it before[7]. That time, I was being paid. This time, I wasn't. I did it quick and dirty.