More GUI (ravings?)

Eric Merritt <>
Mon Mar 3 14:50:07 CET 2003

> I completely agree, and that's why I asked! :-)
> Maybe someone here isn't as "OO-ized" :-)
> I too want to make this completely Erlang-based,
> both in spirit and in implementation. I tried to
> find some references that might help, but again, all
> are OO, or OO-like, or even further from Erlang's
> model (monads and stuff).
> Sub-classing isn't really OO, as it can be used and
> is used at run-time, changing behaviour of things
> defined elsewhere. 

 Hmmm, its a hard problem. The following is after very
little thought so take that into account. I would
think you would have a single process that would
handle the actual drawings to screen. It could
probably take some type of screen description (maybe
similar to what clacke has done in ehtml, it would
have to be much more low level of course). The drawing
process would probably have to extensible, maybe an
init configuration could register rendering routings
for individual atoms in the spec. This would maen that
your logic would have to be devided into two seperate
and distinct areas, drawing and behaviors. Of course,
the drawing process would handle default constructs so
you wouldn't have to extend that if you weren't doing
anything funky. 

 Each event handler would be a seperate process (or
maybe each event should be spun into its own
process?). Hmm, probably event handlers would be
registered to one of two areas, screen coords to get
mouse clicks and keyboard in puts.

 With the mouse clicks and key board inputs you would
probably want to send events in a synchrounous fashion
with the last registered getting the first event and
if you got a valid return value continuing to send
events to other registered listeners. If you got a bad
value (maybe a false?) you could stop sending the

I would think also that the event manager would be in
its own process. 

Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more

More information about the erlang-questions mailing list