Musings on an Erlang UI System

[Chris Pressey]

Well actually it's still embryonic, but I did say I'd post a link so:

  http://kallisti.mine.nu/projects/prism-2003.0216/

(or http://kallisti.mine.nu/projects/prism-2003.0216.tgz to grab the whole
thing as a tarball)

This is about my fourth attempt to implement a nice simple generic data
entry interface in Erlang.  It's still far from nice, but it's finally got
a good shot at simple and generic: there are no records, one module,
mainly property lists.

It uses GTK as a backend, but it could just as easily use GS, HTML, TTY,
voice mail, etc - this is not a GUI, it's an abstract user interface. 

Every form in the demo is created and shown with prism:show/1.

The client specifies as little information as possible about forms and
other objects - only the most general properties like their name,
description and so forth, and never their concrete qualities - these are
always inferred by the engine (which in this little prototype is quite
consistent but quite ugly.)

Validation is peformed with a callback for each field which may return an
ok response and new data, an error response and the reason for it, or an
instruction to update multiple fields on the form.  In hindsight, this is
highly inelegant and it may make more sense to have one validation
function per form that validates all fields at once and returns either an
error or a new structure.

Things that I haven't addressed yet:
- liveliness.  I thought about this a bit, and it's not always a good
thing.  The problem is not in the UI so much as it's a general problems
with shared state.  I think a nice solution might be UI locks analogous to
file locks, but I have to think about it more.
- recursion.  Structures that contain structures should generate forms
which contain subforms.
- dependencies between forms.  Structures that are linked to other
structures should generate forms which allow the user to traverse these
links.  This should include some kinds of dependencies of order, for when
forms flow in a certain sequence as they sometimes do.
- layout manager.  The user should be able to alter their view of how
the data is layed out, for example, by rearranging columns.  The
programmer shouldn't have to deal with that sort of purely aesthetic
change.

Ideally the data structure would match the basic data structuring
mechanism of the language, but that's a lot to ask of structs :)

And that's basically my plan, but it'll take a while to implement it all.
Your feedback is of course welcome!

-Chris