[Chicago] Meeting recap?

Ben Collins-Sussman sussman at red-bean.com
Sat Apr 14 22:00:48 CEST 2007

On 4/14/07, Atul Varma <varmaa at gmail.com> wrote:

> I'd love to see a presentation on this project if Ben's interested in giving
> one, and I'd totally participate in a coding sprint if one was held.

Sure, I could give a talk... though I'm not entirely sure how
interesting it would be to general ChiPy group.  It seems more like
something to talk about after we have working software.

The thing is, the z-machine is complex and pathological.  The
pure-python z-machine implementation is about 60% finished, and at
least half of the remaining parts are UI related.  What makes the
z-machine UI so tricky is that it doesn't really abstract the screen
and user input well.  It's really hard to write a z-machine which
isn't tightly bound to a specific GUI toolkit.

A hero in the IF community made a valiant attempt to create a portable
API to separate 'machine' from 'UI', and it's called GLK... basically
a single C header file that back-ends (interpreters) can use to talk
to front-ends.  So in theory, any number of back-end implementations
can be easily hooked up to a bunch of GLK-compliant front-ends.  This
turns to work out pretty well, assuming all front-ends and back-ends
are written in C.  Since I'm busy writing my back-end in python,
though, I'm stuck trying to swig-ify the glk.h header... or something.
 Haven't figured out the something yet, but it would be nice if people
could help on this.

My current goal is to create a python class (ZUI) which is nothing but
a template with stub functions.  Subclasses could implement real
connections to front-ends.  I'd like to write a subclass which uses
irclib.py, so that the front-end would be an IRC bot (so that multiple
people could cooperatively play an adventure).  Another idea is to
write a subclass which provides a Sugar UI for the OLPC laptop (think
of the children!!).  Finally, we should write a subclass which speaks
to standard GLK-compliant front-ends, via C libraries somehow.

The fact is, defining this UI class is Really Hard.  The game
(program) has to do complex feature-negotiation with the back-end
interpreter, and the interpreter has to do complex feature-negotation
with the front-end.  Eek.

But hey, yeah, hackathon anyone?  :-)

More information about the Chicago mailing list