ANNOUNCE - graphics package

[Joe Armstrong]

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
is easy.

  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
layer.

  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
programming model.

  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
parallel processes.

  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 :-)


 /Joe



> 
> -- O.L.
>