Older blog entries for tjl (starting at number 4)

Well, some typos in the entries below... but I've made a decision to never edit them since otherwise it's not really a diary.

The line breaking problem is getting there... all we need is a normal line breaking algorithm applied iteratively (to determine the starting line). There are some situations in which there is no right answer (if starting later makes the largest line come earlier or some other oddball case) but then we just choose a close one.

Going for an actual vacation on the weekend, the first real rest in a long time (aside from recuperating from flus which don't really count because I started coding the moment I felt up to it). But otherwise, the things to do now are the integration of the linebreaking with the VStream rendering (which must become paragraph-oriented) and we're on our way to cool stuff.

Too bad I won't get to make it work until next week at the earliest. That's the trouble with vacations.

Really interesting problem in Gzz: how to break lines of text in a paragraph when the line where the cursor is must have the largest font and the font size (and possibly width of the paragraph) must taper down on both sides of that. See, the problem is that the paragraph must start on a given point (beginning or slightly indented) from the beginning of the line so we can't start rendering from the cursor. What fun! Probably have to do something like successive approximations.

Whew, after only one hour of sleep, a lot of pending cleanup has been done on Gzz. Met with a student coming to work on the project in the summer, talked a lot about how to do interesting things with ZZ.

New thoughts on what views to do: a billowing (showing text closer to the cursor with a larger font) view with the small, draggable notes shown next to the text. This should be interesting.

Need to take a good look at caching stuff (renderings of paragraphs) in a long VStream to be able to quickly put stand-ins for the most zoomed-out parts.

My architectural philosophy is: "I need to see it working before I can design it". It sounds a bit backwards but it actually works really well: first you hack together something that does what was required or a small subset of that. Then you look at what you did, how it was done and what sorts of changes are necessary. Then you fix that stuff, either throwing all of the first attempt away or cutting and pasting pieces that are suitable for the second version.

GZigZag is beginning to reach the end of the first stage in some areas, and is even in the second stage in some (ZZPersistentDimSpace file format). However, some things I have not even begun the first stage yet on, like networking and slices. Those will make life interesting in the future ;)

I keep thinking about how to make the first interesting structural text demo. What structure etc. One thing I'd like to do at some point but which may be a bit too difficult right now is to take RFC822 (email&news message format), which is long and needs to be read sequentially because of definitions of the formats etc. and make that into REAL hypertext. So that when you look at a definition, the definitions required to understand it float nearby on the screen, reduced in size and you can click and smoothly move into one of them.

First entry. Spent day talking with students, coding GZigZag (some ZZCanvas speedup, rethinking the ZZView model so that the ZZUpdateManager will be able to tell views how much they should skimp on the detail to preserve framerate), and finally reviewing some text for a research grant application for the Dominica project with GZigZag (more on that later).

Debugging with GZigZag really rocks: seeing the structure in question mutate in another view in another window as I operate on it in one window is amazing. And no clumsy debuggers required: it's just different views into the same structure. There's so much I feel is just on the edge of happening with GZigZag.