ANNOUNCE - graphics package

Vlad Dumitrescu vlad_dumitrescu@REDACTED
Mon Jan 19 12:32:41 CET 2004

From: "Joe Armstrong" <joe@REDACTED>
>   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.

This is powerful, but it basically means that every user of ex11 would need to
have a good or very good understanding of the X11 workings and protocols. Which
may be quite a lot, if all one wants is to have a couple of buttons to press and
some text input.

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

I think there is a nother reason too: hiding some of the complexity, and letting
programmers concentrate on the job at hand, not X11.

> In  ex11 I  do *exactly the opposite* and expose the concurrency to the

And it fits Erlang very well!

>   All  the  top-level widgets  speak  directly  to  the X-server,  and
> callbacks  are   not  necessary   -  this  *greatly*   simplifies  the
> programming model.

I'm not sure I understand you fully. We still have to tell the widget what to do
when it receives an "onClick" event, don't we? This can be done with a
traditional callback, or by letting it send a (possibly refined) message to an
application process - but I don't see any fundamental difference. It's still a
link to application-provided code.

Or maybe we are talking about different things?


More information about the erlang-questions mailing list