Musings on an Erlang GUI System.

[Chris Pressey]

On Fri, 14 Feb 2003 06:44:11 -0800 (PST)
Eric Merritt <cyberlync@REDACTED> wrote:

> > 
> > The name object for a compound of data and functions
> > is
> > a good one, it can model physical objects (which
> > have state
> > and are subject to actions).
> > It just happens that one can assemble GUIs out of
> > such
> > objects like list boxes, buttons, sliders, etc quite
> > good.
> > So much for oop.
> 
>   I didn't say it was a bad approach simply that it is
> currently the only approach we have. There have been
> very very few other approaches even researched.

I think this is a false dilemma.  There's no great conceptual conflict
between object orientation and concurrency orientation; you really can use
both at the same time (although you may have to drop some of the
extraneous assumptions put in place by the OOP school).

> This
> is probably becuase the OO approach actually works as
> well as you say. All of this doesn't mean that its the
> best way or even that there are not other alternatives
> just as good.
> 
> > The other common feature of modern GUIs is that they
> > are 
> > event driven apps, with many visual components
> > running in
> > parallel. The event wiring of the components is a
> > bit ugly.
> > That part should be easier in Erlang.
> 
>   
>   Ah yes, but the event loop is *generally* entirly
> driven by the user. It is very hard to create a nice
> interface that is reactive to both the user and
> arbitrary external stimuli.

As a fairly heavy user of Erlang/GTK+, I've found 'inputs' (callbacks to
react to arbitrary messages) serve this purpose well.

>  
> > > I realize that most everyone on this list at the
> > > moment is a server side guy (I am myself by and
> > large)
> > 
> > I did much GUI hacking in the past, I hope this will
> > benefit
> > the erlide. :)
> 
>  I sure hope so (on the side I have finished a bit of
> the prelimiary docs, will post them soon).
> 
>  
> > > Perhaps this could be one of the many killer
> > aspects
> > > of Erlang that would help draw users.
> > 
> > Important for GUI development IMHO are
> > - the GUI must look professional (win95 or Aqua
> > look)
> 
>   I think to extend this thought, the gui look and
> feel must be very easy to change. Whats cool now will
> not be cool in five years, and what cool in five years
> will not be cool in ten, etc, etc. So its got to be
> easy to change and keep up to date.

As a pragmatic individual, I couldn't disagree more - a slick look and
feel is a low priority (when compared to robustness, consistency, and
portability) unless the intent of this project is to wow propellerheads,
middle managers, and other easily-impressionable people.

> > - the GUI must act snappy (not more than .5s delay
> > on user interactions)
> 
>  Yup

Yes, in other words, UI should be an excellent match for Erlang because
UIs are soft real-time.

> > - there must be builder tools which enable people to
> > slam together
> >   GUIs very quickly
> 
>   Yes but this could come much later. Once the gui is
> complete.

Again, I completely disagree; having used a lot of really bad VB apps, I
have to say that a UI which has been slapped together probably isn't worth
using.

On the other hand, being able to generate a generic form based on the
underlying data and actions taken by the form would is very handy - but
only for equally generic applications.

> > - it should not crash
> 
>  Yup
>  
> > Java has some advantages when it comes to quick
> > development,
> > but depending on the visual complexity of the data
> > performance
> > penalties.
> > Qt is nice for cross platfrom development.
> 
>   I am thinking that instead of picking an already
> created gui to wrapper, instead it would be best to
> create or find a graphics kernal that would be easy to
> port. Then let erlang handle everything else.

This would also be the way to address robustness - Erlang doesn't
magically make port programs reliable :)

-Chris