ANNOUNCE - graphics package

Joachim Durchholz joachim.durchholz@REDACTED
Mon Jan 19 19:06:53 CET 2004


Vlad Dumitrescu wrote:

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

In principle, you're right. The problems lie in the details.

A user-defined message is easy to program, but you'll have to make sure
that its code doesn't collide with the message code of another
user-defined message. Which means you have a global dependency between
modules, and most GUI frameworks handle this aspect poorly, and for
those that do, the application program has to register any new message
handler so that it gets the message code it can use, which then must be
held in a (global, of course...) variable.
In short, it's a hassle. The main reason is that the user code that's
supposed to get/handle a message must be selected according to the
message id, and this dispatch is globally defined (by necessity: typical
GUI applications listen on exactly one message queue). If you're not
ultra-careful, you'll end up with all sorts of globals in your library
design.

Callbacks are difficult as well. You have to provide the environment for
the called-back function, so that it can access other elements of the
GUI elements (e.g. a button may react differently depending on the
validity of input fields' contents).
Easy for Erlang processes.
Difficult for a C function. Usually, you have to pass a pointer to the
GUI framework, to be passed back to the C function when it's called
back. With all the typecast hassles that this involves.
Easier for closures, particularly if the language gives them access to
mutable state. Well, such closures can do the Erlang process model in a
one-on-one fashion, so that's not a real surprise :-)

Been there, done that, got the T-short.
(I used to work on a GUI library in my last job. That was for MS 
Windows, so details may vary a little, but the basic issues should be 
the same for X. The main difference is that you have far less messages 
to care about in X, but essentially you still have to carry the same 
information between server and client.)

Regards,
Jo
--
Currently looking for a new job.




More information about the erlang-questions mailing list