Yes. Right Into The Camera. Yes.

It seems congratulations are in order:

• All hail M-Biddy for getting a job -- at OpNet, the Pentagon's largest supplier of nuclear missiles and Arab-killing gases! No, that's not what it is; it's some boring god-damn networking thing
• All hail Devlin Smithers for making. more. money.

This ncurses project I'm working on is starting to get pretty interesting -- what I'm doing is creating an ncurses rendering target for XML-based user-interface toolkits. ncurses, by the way, stands for "new curses," and curses, by the way, is this fairly hoary UNIX library for doing low-level manipulation of terminal screens. Think text-mode graphics, basically. The problem with ncurses is that, while it makes it very easy to, say, draw a single character at particular place on the screen -- no easy feat with the standard set of system calls and libraries in UNIX, mind you -- it is horrendously difficult to render a full screen of "widgets," like boxes, buttons, text input controls, etc. On the other hand, though, you've got these XML user-interface-markup document types, like XUL, where you can quickly and easily specify things like buttons and check-boxes and whatever. Here's what a little piece of XUL might look like:

<box id="main-box" align="center" border-width="1">

  <label id="main-box-label" text="Click the button below"/>

  <button id="main-box-button" text="Click me!"/>

</box>

It's pretty obvious what that's gonna look like, right? And it was super-easy to write, too. Here's the problem: Currently, the only real renderer for XUL is called Gecko -- it's what renders HTML for Mozilla Firefox, too -- and so you need a raster-based GUI like X11 or Win32 to run it, and this doesn't help anyone at all if they're trying to develop text-based applications. So what I want to do is make it so that you can feed in that XUL to ncurses and have ncurses draw it in text mode. This is not an unreasonable proposition, since the majority of the widgets specified by XUL don't specifically require pixel-level control of the display device.

Where it gets interesting, though, is in trying to figure out where to draw these things on the screen. I found a little bit of information on this at the Gecko development page, but for the most part I have to figure it out myself. HTML, see, uses what's called a "flow" based layout paradigm, which means that you more or less assume that a "page" can be arbitrarily long, so that if there's an element that absolutely needs to be a certain size, then the other elements can wrap around it or go after it, and you basically can just put things in the next available space on your infinitely long or wide page. XUL, on the other hand, as well as other rendering kits like Gtk, are "constraint" based, which means that there's a certain maximum size (such as an application's window) and you're not allowed to exceed that size -- so if you give all your elements leeway to take up as much space as they want, you might not have room for all of them. So maybe you have to squish some of them a little, and even then you still might not have enough room. Basically, constraint-based layout algorithms are more likely to fail than flow-based ones; and that's okay -- it's interesting, even. So I'm trying to write some layout code now. We'll see what happens.

Adam Cadre finally got some essays up about the election -- it's a lot of material, but it took him like a week and a half, too! The more of his shit I read, the less I think I'd like to hang out with him personally, but that doesn't mean he doesn't make a mean bean dip.

I want to do something this weekend, but I think I'm getting sick. We'll see.

Oh yeah, here are links to some 'blogs that I found; I'm not gonna create permanent links to them because I'm not especially close friends with their respective authors, but some of you might be, so:

• Rachel "Dratch" Wasser's 'blog, The Asian Invasion. She's in Hong Kong right now?
• Sam Culp's 'blog, New Territories. She's also in Hong Kong.
• Justin Charles' 'blog.