More GUI (ravings?)

[Peter-Henry Mander]

Maybe I'm way of the mark, but why not use Erlang messages as you would 
OO "messages"? So if you "inherit" from a generic widget, you 
selectively receive the messages the "subclass" module process uses and 
delegate the rest to a "superclass" module process. I think that a deep 
inheritance tree means lots of layered processes, but there again Erlang 
apparently copes with that very well.

I kinda like the ability of this model to pipeline the messages toward a 
superclass instance, but a round trip of sending a message to the 
base-class module an receiving the response may have an impact on 
responsivity. But maybe the concurrency in Erlang will offset this.

Am I utterly deluded? If this works, why insist on a FP UI model? Could 
it be a better match for the asyncronously networked nature of X11?

Pete.

Eric Merritt wrote:
>>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
> event. 
> 
> I would think also that the event manager would be in
> its own process. 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 
>