Musings on an Erlang GUI System. [long, very long] ramble... ramble ...

[Eric Merritt]

I have seen it said on this list on more then one
occasion that Erlang is not well suited to do any real
GUI work. I have even agreed with it on more then one
occasion. However after spending a little time
thinking about it I have changed my mind.

 Granted at the moment all we have is a string based
interface to TK. Obviously, this leaves allot to be
disired. The implementation is good, but it is limited
by the technologies used. 

 To meander off topic for a moment ....

 I lurk on the squeak list quite a bit. They have
implemented a gui system called Morphic. Morphic is a
nice gui system (undocumented and hard to use but
nice). One of its principle tenents is that of
liveliness, this means allot of things, but mostly it
means that the object is reactive. When a user clicks
it has the tactile feelings of being 'picked up'
animation is easy the gui is never locked up in a
process etc, etc.  I was thinking about this and how
easy it would be to implement liveliness in Erlang.

  Now back on topic ....

 Over the last couple of decades (since the birth of
smalltalk actually) GUIs have been dominated by Object
Oriented languages. Perhaps this is becuase its simply
easy to think of a button as an object or becuase when
GUIs where new and interesting they where implemented
as objects. Even the GUI systems written in procedural
languages like C (gtk, etc) have an object oriented
feel to them. At this point it doesn't matter really.

 To move on. I am begining to think that Objects are
probably not the best way to implement a gui at all,
but processes may just be. Why? well I think it will
help add two features to GUI systems that are sorely
needed. First, I believe it will help to add
Liveliness  in that checkboxes, buttons, anything
really can have its own independent, concurrent,
behavior. It may even lead to other more interesting
ideas, perhaps even away from the staple buttons and
boxes that have been our crutch for the last twenty
years. 

 The other thing that using Erlang would provide is
*robustness* which every GUI system lacks right now.

 I realize that most everyone on this list at the
moment is a server side guy (I am myself by and large)
but perhaps that would give us a fresh perspective on
the problem and allow us to tackle the problem from a
diffrent perspective.

 I have nothing to offer yet as far as an
implementation is concerned but I will think on it.

 The only core thing that is currently lacking is some
type of drawing and rendering api, and perhaps the
Erlang SDL project would work for that (along with a
few pieces of wings).

Perhaps this could be one of the many killer aspects
of Erlang that would help draw users.

 Sorry of the length and unfocused nature of the post,

Eric
 

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com