Speaking of the plague, does it support UIL? ;)<p>Neils Mayer described WINTERP (XLisp + Motif) as: You might think of such functionality as "client-side NeWS without the postscript imaging model".<p><a href="http://nielsmayer.com/winterp/" rel="nofollow">http://nielsmayer.com/winterp/</a><p>Don Hopkins wrote to a comp.human-factors discussion about "Info on UIL (User Interface Language)" on January 22, 1993:<p><a href="https://groups.google.com/d/msg/comp.human-factors/R3wfh90HMss/WR1-qmjnNJIJ" rel="nofollow">https://groups.google.com/d/msg/comp.human-factors/R3wfh90HM...</a><p>Here are some classic messages about UIL. Avoid it like the plague.<p>-Don<p>To: xpert@expo.lcs.mit.edu
Cc: Erik Hardy <e...@sei.cmu.edu>
Subject: Re: To UIL or not to UIL?<p>From: Niels P. Mayer <mayer%...@hplabs.hpl.hp.com><p>In article <?@?> mi...@portia.Stanford.EDU (Michael Yang) writes:<p>> In article <5...@tci.bell-atl.com> ke...@tci.bell-atl.com (Cory Kempf) writes:<p>> >I need to build an application that uses X/motif. What I need to
> >decide is if we should use UIL or not. Or maybe WINTERP? Are there
> >any strong oppinions out there one way or another?<p>> One advantage of using UIL, is that it's portable and is part of Motif
> from OSF (though for some reason, HP's "Motif" release doesn't include
> it).<p>I don't work for the product division responsible for HP's X products, and
I don't claim to speak for them. However, the rumor I heard is that UIL
wasn't included in HP's product because "it didn't meet HP's quality
standards for a supported software product." This is only a rumor, talk to
someone in charge for the official poop.<p>The unofficial poop, which is my personal opinion (and reflects the
opinions of others older, more experienced, and more learned than I) is
that UIL SUCKS. The idea itself is somewhat silly, the implementation is
buggy; and it is an inelegant solution to application customization.
Finally, UIL doesn't make life as an application programmer any easier --
It requires that you learn yet another programming language that is
completely nonstandard, UIL, alongside a number of Motif resource manager
calls. You have to master all that while trying to understand the
interactions of the large number of features in the Motif toolkit. The
recent questions we've seen on this group about getting back the widgetID
for a widget created in UIL is a good example of the kinds of cruft that
you can expect when doing any sort of serious programming with UIL. And I
wouldn't expect to see any example-laden books like Doug Young's excellent
Xt/Motif text for UIL application programming in the near future.<p>In sum, if I didn't have WINTERP around, I would prefer to program in
straight C rather than use UIL.<p>It still escapes me why UIL was ever built the way it is. The Motif widgets
are essentially "interpretive" in that you can give programmatic commands
to the Motif library to create new widgets, and the Xt intrinsics will
create the new widget on-the-fly. You can also send messages to created
widget objects via the "methods" in the Xt intrinsics, and especially via
XtSetValues() -- these changes are also interpreted by the intrinsics and
result in an eventual updating of the visuals associated with the widget.
The only thing that is "compiled" about widgets is the order that they
appear inside their "manager" and that ultimately depends on the
implementation of the manager widget.<p>UIL is thus a compiler for an interpreter. UIL compiles a widget layout
(specified in a UIL text file) into a UID (user interface definition) file.
A UIL-based application then uses the built in Motif resource manager to
read in the compiled description of the layout in order to produce a user
interface. UIL then makes the claim that this can be used to drastically
alter the look of an application independent of the program's semantics
(e.g. what the CHI community would call a "UIMS"). I seriously wonder how
drastic an alteration is possible without providing deeper hooks into the
semantics of the application itself. Alas, UIL is not a programming
language, so that is impossible.<p>Imagine, for example, what would be required to turn a "pushbutton-based"
application, such as the X11r3 xmh into a Mac-style "pulldown-menu based"
application? How are you going to describe the semantics of the way the
current-selected message in the browser interacts with the current-selected
folder (selected via pulldown menu or dialog box) and the actions
move/copy/delete (also selected via menu)? Are you really going to be able
to describe both styles of interface with UIL?? Or are you going to have to
provide two different styles of hooks in the application itself -- one UI
hook for the pushbutton-based UIL interface, and another for a menu-based
UIL interface. If you have to enumerate and hard-code every conceivable
dialogue style in the application, is UIL really a useful UIMS??<p>No, really all that UIL gives you is an extension of the old "Xdefaults"
scheme of customizing an application. Yes, UIL's syntax makes it clearer
which Xdefault resources will affect which widgets. Yes, UIL does allow you
to specify the widget hierarchy and callbacks in an interface. However,
customizing a UIL application will continue to be as tedious, if not more
tedious than it is to currently customize an application via resource
settings. The current state of X applications is that you set X resources
(via editing .Xdefaults or twiddling with xrdb) and then run an appliction
to "interpret" the resource settings. If things don't turn out right, you
quit the application, edit your resourcre file again, and rerun the
application. Anybody that has tried this knows it is tedious, especially if
the application does alot of startup processing. UIL gives you the same
tedium, with an additional compilation step thrown in. Sounds like a great
idea, no?<p>And to make things worse, it is quite difficult to extend UIL to handle new
widgets. While the Motif toolkit does provide a broad coverage of UI needs,
serious applications may end up using at least one new widget not contained
in the existing Motif widget set....<p><pre><code> --------
</code></pre>
WINTERP attempts to solve some of the problems that UIL claims to solve,
but it takes a completely different tack. WINTERP gives you access to the
"interpretive" nature of the Motif widgets through its built in mini-lisp
interpreter (XLISP). The lisp interpreter and the interactive interface to
widgets are useful both in prototyping an application, as well as allowing
an end-user to customize a delivered application.<p>For prototyping, WINTERP allows you to incremetally build up a user
interface, piece by piece. It also means that you can "play" with the
interface, modifying both the look and feel of the application
interactively. WINTERP even includes a "direct manipulation" primitive that
allows you to change widget resources, callbacks and eventhandlers by
designating a widget with the mouse. With WINTERP, one need not suffer the
tedium required in rerunning or recompiling the application in order to
make a change to a UIL or X resource -- incremental changes to an
application can be tested interactively.<p>Unkike UIL, WINTERP's widget-description language is based on a REAL
PROGRAMMING LANGUAGE, which enables you to use the language to represent
and manipulate the state of the application and the UI. UIL is not a
programming language, so you can only describe a widget layout, only mock
up prototype a static interface; you have to go through alot of trouble in
order to link up the functionality of your application with the dynamic
dialog-style of display that makes up a real application. WINTERP, on the
other hand, will allow you to prototype the dynamics of the interface. In
fact, WINTERP makes an excellent applications prototyping environment
because you can use an interactive, high-level programing language to build
the user interface AND also prototype the "dialogue" aspects of the working
application.<p>For customizing a delivered application, WINTERP's language interpreter
allows users to interactively modify the interface and customize
application functionality. WINTERP-based applications that are designed
for customizability will contain C-implemented lisp primitives to
accomplish core functionality which the customizer can "tie together" via
interpreted lisp. Applications might come with a set of predefined
interface libraries that enable different interface styles, such as the
pulldown- versus button-based style mentioned above. Users may use
"programming by example" to mix and match features and functionality
available in example interface profiles in order to come up with an
application better tailored to their needs. Often repeated commands can be
included in new menu or pushbutton entries, and commands themselves can be
modified to suit the user's needs.<p>WINTERP helps promote an "open", tailorable architecture for applications
because designers recognize that they cannot foresee all the possible needs
of the end-user. Applications like gnuemacs and autocad have shown that
such architectures are very poweful indeed. In addition to being "open" to
the application customizer, WINTERP is also "open" to other applications
because WINTERP's lisp interpreter is a SERVER (using TCP sockets). Other
applications, possibly running non-locally, can send lisp commands to a
WINTERP-based application in order to execute functionality internal to the
application. Such an architecture allows applications to talk to each
other, share data, etc. You might think of such functionality as
"client-side NeWS without the postscript imaging model"....<p>The choice of Lisp as the widget layout and prototyping language in WINTERP
provides numerous advantages. Lisp programs are in the same form as lisp
data. That means that lisp programs can easily perform computations to
create/alter data structures representing lisp programs. This sort of
meta-programming is especially useful in WINTERP because a user interface
description in winterp-lisp can be treated both as data as well as a
programmatic description of a user interface. That means you can use
winterp-lisp to create all sorts of dynamic widget layouts through lisp
computations that create and mutate data strucures representing
user-interfaces. We are using this feature in our groupware toolkit to
allow active user interfaces (akin to "forms") to be created, filled out,
program-transformed, shipped around via e-mail, and then interpreted on the
receiver's workstation to pop up an active form.<p><pre><code> --------------------
</code></pre>
UIL could be useful however -- rather than being a "compiler for an
interpreter", UIL could become a real compiler that took a structured
description of an interface's widget hierarchy, the resources used, the
callbacks, eventhandlers, etc. All that information could then be compiled
into straight Xlib + C code that would be much more efficient in size and
server resource usage than the equivalent Motif/Xtoolkit calls. Kludges
such as "flattened widgets" and "gadgets" wouldn't be needed because the
compiler would be able to figure out which server resources, gc's, and
windows could be shared by widgets based on "type declarations" and
"constant declarations" gleaned from the UIL file.... (and then I woke up
from my dream).... this would obviously be one heck of a compiler
project...<p><pre><code> --------------------
</code></pre>
For more information on WINTERP, see the X11r4 contrib distribution --
contrib/clients/winterp/doc/winterp.doc and
contrib/clients/winterp/doc/winterp.doc. If you are planning on building
WINTERP from the X11r4 contrib tape distribution, you must apply the
patches posted to comp.windows.x/xpert on 1/8/90 (titled
"Patches to X11r4 contrib/clients/winterp (Motif application prototyper)".<p>Better yet, retrieve WINTERP via anonymous ftp from expo.lcs.mit.edu. In
directory oldcontrib, you will find the following:
-rw-rw-rw- 1 ftp 6252 Dec 19 08:57 winterp.README
-rw-rw-rw- 1 ftp 605837 Dec 19 08:57 winterp.tar.Z
In directory oldcontrib/winterp.binary, you'll find:
-rw-rw-rw- 1 ftp 808483 Dec 19 06:46 hpux-s800.tar.Z
-rw-rw-rw- 1 ftp 605899 Dec 19 06:43 hpux-s300.tar.Z<p>----------<p><pre><code> Niels Mayer -- hplabs!mayer -- ma...@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*</code></pre>