ANNOUNCE - graphics package
Mon Jan 19 11:40:39 CET 2004
On Fri, 16 Jan 2004, Olivier Lefevre wrote:
> > IMHO the ex11 graphics stuff is *much* easier to program than TCL since
> > you can *directly* hit the X protocol level.
> > In TCL/TK you have to *change languages* to do real tricky stuff (ie you
> > can no longer program in TCL to do tricky things but have to change to C)
> Agreed! So ex11 is sort of like Swing for Erlang, albeit running only on Unix(-ish)
> platforms. Did I get that right?
Possibly, I've never used swing.
Since the first release of ex11 I have realized that ex11 is much
more powerful that TCL/TK or any other graphics package that I've seen.
The reason has to do with the concurrency modeling. In my ex11 GUI
widgets *every* object you can see on the screen is a process.
Buttons are processes, labels are processes, sliders are processes
etc. They all obey a generic protocol and all operate concurrently.
Thus adding (say) a clock (which needs some concurrency) to a button
In the widget framework all S/W layers have accesses to the display
socket (via a library) so *any* process (including application layer
processes) can bypass all library code and talk *directly* with the
X-server itself - ie any S/W at any point can do any operation
directly against the X-sever and does not need to go through a library
The bottom (driver) layer is merely a thin interface to the
X-protocol. By directly sending X-protocol messages and by directly
delivering X-protocol messages to the widget controlling process we
eliminate all call back routines and can do anything that X can do.
It turns out that with 20 odd protocol messages one can do *most* of
the fun things that are possible with X. The entire design of
virtually all widget sets (motif, GTK etc) seems to be predicated by
the desire to simulate concurrency with callbacks. In ex11 I do
*exactly the opposite* and expose the concurrency to the applications.
All the top-level widgets speak directly to the X-server, and
callbacks are not necessary - this *greatly* simplifies the
This style of programming is impossible without very light-weight
processes since it would be a nightmare to (say) fork of a new OS
process for every button or label or slider in a GUI ... so this style
of GUI programming is very rare - this is a shame - since it seems to
me that the "natural" way to model a GUI is with a large number of
I'm often suprised when things stop working in traditional
GUI's. For example, when you drop down a menu what's going on
elsewhere in the GUI often stops - presumably because concurrently
handling the menus and all other activities is just too difficult to
program. In ex11 it's easy :-)
> -- O.L.
More information about the erlang-questions