Musings on an Erlang GUI System. [long, very long] ramble... ramble ...
Fri Feb 14 14:18:12 CET 2003
I know that I will have a future need to marry GUI technology with Erlang if
we decide to move away from our HTML-based "GUI".
There are already signs that we will need to do this so I am curious to see
where this goes.
----- Original Message -----
From: "Eric Merritt" <>
Sent: Thursday, February 13, 2003 11:05 PM
Subject: Musings on an Erlang GUI System. [long, very long] ramble... ramble
> 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
> 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,
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
More information about the erlang-questions