[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI, Tk, with-wish

[Message forwarded from Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>.]

>>>>> "BH" == Bruno Haible <haible@ilog.fr> writes:

BH> Matthias Lindner wrote:
>> I have tried different built-in GUIs for CommonLisp (Lucid with
>> LispView, Allegro with CommonWindows, CLISP with StdWin, CLIO). 
>> Forget it - period.
>> That's why I wrote with-wish.

BH> That's a clear statement. :-)

Yes, but let me add some more points, after my last mail. Btw, my
statement comes from 5 years intensive development with and research
on GUI development environment, as part of my Ph.D. project on
formalization of UI toolkits and their interface to GUI DEs.

BH> It looks like the big packages Garnet, Amulet, CLIM
BH>   * are hard to learn (huge libraries),

I don't know about real usage of CLIM, but in Garnet and Amulet, you
don't use the libraries. You use higher order tools, the libraries are
created especially to support the functionality needed by these higher
order tools. They support creation of event/action bindings by
demonstration (nowadays made popular in a simple way by the Java Beans
DEs), specification of interfaces by demonstrating constraints to be
obeyed by the UI, infer higher-order actions from examples supplied by
the designer, etc. You won't do this by hand, believe me.

It's some time ago (about 5 or 6 years) that I did experiment with
Tcl/Tk. It was a good system for programmers, providing nice
abstractions for UI creation on the level of formal imperative
descriptions with a simple listener model (active objects). Judging
from the documentation I read the last two weeks, that didn't change.
But if one had ever a chance to create GUIs with a
programming-by-example interface, one will never praise any
programming approach as the one-and-only-system-with-the-best-
productivity. Even working with the NextStep UI builder is by far
faster than with any toolkit approach.

So, in the topic at hand, the rush towards Tk is a sensible one. I just
disagree with the arguments; other systems -- representing the state
of the art in UI DE technology -- should not be dismissed because they
don't provide low-level abstractions one would like to use `by hand'.
If people want a simple UI toolkit, fine. But for projects where real
designers (i.e., persons without programming experience) are involved
and a whole series of rapid prototypes for requirement definition and
usability testing is a must, one needs different abstractions.


Joachim Schrod					Email: jschrod@acm.org
Net & Publication Consultance GmbH		Tel.:  +49-6074-861530
Roedermark, Germany				Fax:   +49-6074-861531