"Joel VanderWerf" <vjoel / PATH.Berkeley.EDU> wrote in message
news:40758C97.6070906 / path.berkeley.edu...
> The "specification language" style of GUI programming is very tempting,
> but OTOH the Fox API is pretty good already, so that's one reason why
> it's still on my to-do list :)

You've been too close to your own code ;)  Browsing your FoxTails examples,
there is so much Fox stuff around, specially around initialization, that it
makes it quite hard for me to see the essence of FoxTails.

> Maybe the possibility of abstracting from the particulars of the GUI
> toolkit is the point that will tip the scales towards this specification
> approach.

Hmmm. From platform-independent toolkit to toolkit-independent platform? If
doable, it would make a lot of very protracted and agonizing decisions about
which toolkit much simpler for a whole bunch of poor saps like me.

> I'm also interested in the explicit state machine idea that came up
> elsewhere in the this thread, and the possibility of integrating it into
> FoxTails. Observable attrs can already be thought of as synchronization
> of state machines, but the state is just a bunch of variables. Sometimes
> it is useful to have an explicit notion of state in the sense of
> "discrete mode" and explicit transition rules, entry/exit actions, etc.
> Expressing state in this way, if possible, may be clearer than just
> using some related variables and observer code.

I fully agree. Perhaps the Observable underpinnings could
re-establish/maintain invariants that hold within any given state. A
low-level example: list.selection =
list.first_matching_prefix(text_field.value).