More GUI (ravings?)

[Chris Pressey]

On Mon, 3 Mar 2003 11:32:57 +0100 
"Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu@REDACTED> wrote:

> Hi all,
> 
> Since I am working on ex11, I am also trying to see what might come
> ahead and try to plan for a possible widget toolkit, implemented in
> Erlang. As I said once before, I can't see any way to do it in a
> different way that it is done in most other languages, that is OO or the
> like. Please if there is anyone that has a link to a GUI framework that
> isn't OO (but not too far from Erlang's philosophy either), send it to
> me.

The structural parts of GUIs tend to be modelled as OO objects, because,
well, it fits.  But there are other aspects that don't get as much press -
GUIs almost universally work in terms of events when it comes to the
dynamic aspects, and rules when it comes to layout - but these generally
get downplayed, because the structure is more 'obvious' to the
visually-inclined end user I guess.

> The "missing feature" that would be needed has already been discussed
> here in many ways: building a hierarchy of behaviours. Or with another
> word, implementing subclassing. A generic window has behaviour that an
> input widget will "inherit" and that one can further be refined to
> become a "password input" widget. 
> 
> The question is how to delegate the "inherited" behaviour to the right
> implementation module?
>
> ----
> One way is to just write lots of funs similar to
> 	set_visible(Widget) ->
> 		widget:set_visible(Widget).
> But this seems very heavy on the typing fingers and not extendible.
> Maybe some macros could help, but it would look like a C++ framework
> from 
> 
> Another way is to use for example an attribute
> 	-inherits([widget]).
> and then either:
>    * change error_handler:undefined_function to check any modules named
>    in 'inherits' for the respective function before reporting an undef
>    error

While this would work great, for better or worse, it's not very Erlang-y.

I think the Erlang-y solution would be

  loop(Parent, State) ->
    receive
      ...
      AnyMessageIDontUnderstand ->
        Parent ! AnyMessageIDontUnderstand,
        loop(Parent, State);
    end.

But honestly, I like trapping undefined_function better - this
pass-the-message-through-back-to-the-parent-process way will
result in a *lot* of processes, and even though that's OK here, it still
feels wrong - because the processes seem *superfluous*.  One process per
real-world activity - the textbox underlying a passwordbox isn't *really*
a discrete real-world activity, is it?  It doesn't seem to have an
existence independent of the passwordbox, to me.

-Chris