🚀 go-pugleaf

In article <1jn5tiINNo7p@nic.umass.edu> gbc@neural.hampshire.edu (Gary Cote) writes:

   From: gbc@neural.hampshire.edu (Gary Cote)

   Can somebody give me some info about UIL (User Interface Language)?
   I understand that it was created by Digital, that it creates a
   textual representation of a user interface, and that it is somewhat
   of a standard (?). 

   How much of a standard is it?  Does it extend beyond the DEC
   platform at all? 

   Does it support, or is it dependent on, X?

   Are there any public domain utilities that make use of it? 

   Thanks for any pointers.

   Gary Cote

   gbc@neural.hampshire.edu

Here are some classic messages about UIL.  Avoid it like the plague.  

	-Don

To: xpert@expo.lcs.mit.edu
Cc: Erik Hardy <ejh@sei.cmu.edu>
Subject: Re: To UIL or not to UIL? 
From: Niels P. Mayer <mayer%hplnpm@hplabs.hpl.hp.com>

In article <?@?> mikey@portia.Stanford.EDU (Michael Yang) writes:
> In article <553@tci.bell-atl.com> kempf@tci.bell-atl.com (Cory Kempf) writes:
> >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?  
> 
> 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).

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.

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.

In sum, if I didn't have WINTERP around, I would prefer to program in
straight C rather than use UIL.

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.

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.

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

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?

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

				--------

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.

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.

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.

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.

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

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.

			--------------------

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

			--------------------

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

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

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *

Date: 19 Jan 90 09:53:11 GMT
From: umich!umeecs!anon@yale-zoo.arpa  (Omar S. Juma)
Subject: Re: To UIL or not to UIL?
To: xpert@expo.lcs.mit.edu

In article <11658.632634712@hplnpm> mayer%hplnpm@HPLABS.HPL.HP.COM (Niels P. Mayer) writes:
[Heavily edited]
>
>                                           ...rumor...           ...UIL...
>                                         ...didn't meet HP's quality...
>            ...poop...
>  ...UIL SUCKS...                        ...silly...
>...buggy...         ...inelegant...
>          ...doesn't make life...                            ...easier...
>...completely nonstandard...
>

I absolutely agree.  I've only had 4 years of serious software
experience, and UIL is the ***worst*** language/compiler combination I
have ever seen.  Nothing, not even working with punch cards, has left me
with a more bitter taste in my mouth.  If UIL were a car, not even the
Russians would want to manufacture it.  If UIL were a--but, wait a
minute, let's be objective for a minute:

*	The UIL compiler does not invoke cpp before it starts its
	journey.  Yo, DEC!!!  Even xrdb uses cpp.  There are several
	advantages to using cpp.  Hey, guys, ever heard of macros?  Huh?
	What's that you say?  You wanted to create your own macro
	facility?  Oh, I see, in the next version.  When's that?  Huh?
	Next year?  Oh.  But what do we do in the meantime?  Huh?  Did
	you say "copy and paste"?  Isn't that kind of inelegant?  I tried
	that.  It bloated the simplest UIL files to thousands of lines.
	What?  Yeah, thousands, not hundreds.  Made them difficult to
	edit.  Huh?  Split the files, you said?  I dunno, that's kind of
	old-fashioned, rather stupid.  Say what?  I can run the file
	through cpp first?  Yeah, I tried that, in fact, since I had no
	intention of wading through huge UIL files; it gave me vertigo.
	Huh?  You want to know how that worked, you say?  Well, I ran
	into this problem, see.  After I did a few nice macros and got
	ready and all, I ran the UIL compiler.  I got this strange error
	message.  It told me that maximum line length was 132 characters.
	Huh?  Well, see, some of my macros were rather long, like 140
	characters, see, and I couldn't make them less than 132 short of
	compressing all the whitespace out of the macro and turning it
	into one huge token.  Huh?  You never thought anyone would ever
	write macros bigger than 132 characters?  Oh, well, I did.

	[Quiz of the decade:  Where did DEC come up with 132?  What, is
	it 128 and a bit?]

*	Defective error reporting.  What do I mean by defective?  Like,
	it's almost impossible to figure out what the UIL compiler means
	when it complains about something.  Like, if you forget a
	semicolon someplace, the compiler pukes into its own food, eats
	it back again, and pukes it out again, and just gets totally ill,
	dude.

*	Documentation.  Huh?  Did someone say documentation?

*	Language design.  Whoever designed UIL must have been heavily
	involved in BASIC and FORTRAN, because that's as sophisticated as
	it ever gets.  The language is extremely simple-minded.  No
	conditional processing.  No interface actions.  No anything.  All
	UIL offers is a substitute to writing out almost the exact same
	stuff in a C program.  Yes, I know that writing it in C would be
	even more time-consuming, but there I have access to powerful
	macros and procedural mechanisms, not to mention conditional
	processing, that can make life easier.  Any intelligence in the
	interface must be performed in the program anyway; you can't
	delegate any actions to the UIL portion, as Niels says.  Which
	brings me to wonder why OSF never gave Open Dialogue any serious
	consideration (please, don't tell me about "demonstration
	technology").  If not the entire Open Dialogue system, then at
	least the language, which was several generations ahead of UIL.
	My personal impression is that DEC shoved UIL down OSF's throat
	as its "contribution", though in effect all it's done is cause
	people to waste inordinate amounts of time and effort creating
	workarounds.

*	Scale.  You really cannot write a serious application using UIL
	and its compiler.  The mechanism simply cannot handle the sheer
	volume of text required to describe the interface.  You need an
	intermediate agent, and OSF just didn't think it was necessary to
	supply one.  I would have settled for preinvoking cpp, but even
	that is not enough.

*	Elegance.  If you try to develop an application using creation
	callbacks and the other standard mechanisms supplied by OSF, you
	will end up with a horrendous piece of noodle code on your hands.
	UIL lends itself very well to kludgy solutions; I tried hard to
	extricate myself from all this mess, but it was not possible
	unless I adopted several coding and pre-compilation standards.
	In essence, I've spent the better part of two months fighting the
	UIL mechanism, trying to create a logical framework around which
	I can develop several large applications, and I'm getting close
	to completely throwing in the towel and starting from scratch
	with WINTERP.  I've looked everywhere, and all I see is square
	pegs that have been shoved and squeezed into round holes.  You
	can't go very far with such a setup.

*	Extensibility.  Are you kidding me?  Extend UIL?  I'd rather go
	gene splicing than try to tack on more crud to UIL.  DEC has
	supplied what can be generously called as an embryonic extension
	mechanism.  It's badly documented, and from what I've seen by
	wading through the code, they never really thought anyone would
	want to extend it.  Like, dude, there's everything you'll ever
	need there anyway, so why bother?


I'm really sorry to be saying all of this, but UIL is not a solution.
Unfortunately, unless OSF is willing to break with tradition and supply a
completely different mechanism for the next release of Motif, we are
stuck with UIL for quite a while.  Which means we will all waste more
time and energy coming up with solutions.  Here's some alternatives:

*	Create a wrapper around UIL.  Bury it under a ton of macros,
	processing languages, prepackaged C code.  Then it may be
	possible to develop an interactive interface editor that uses
	these mechanisms.  This is what I'm currently trying to do, but
	as I said, I'm thinking of giving it up.

*	Get the format for UID files and develop your own UIL language
	and compiler.  This is fairly time-intensive, but offers the
	chance to start from zero and build the system correctly.

*	Use WINTERP.  I'm just not sure about this now, but it's starting
	to make more and more sense.

*	Use LISP entirely.  Don't even bother with C, C++, Pascal,
	FORTRAN, or anything similar.  Start with LISP.  Develop
	everything in LISP.  This seems to be the most intuitive
	alternative, but it requires ***a lot*** of work.  And it's not
	entirely portable, at least not yet.


I could go on...


anon@eecs.umich.edu

...anon...

Date: 27 Mar 90 13:36:06 GMT
From: snorkelwacker!spdcc!tauxersvilli!alphalpha!nazgul@bloom-beacon.mit.edu  (Kee Hinckley)
Subject: Re: UIL or NOT to UIL
To: xpert@expo.lcs.mit.edu

I tried to reply directly to this, but auto-trol.com doesn't seem to
be around, so...

In article <792@auto-trol.UUCP> marbru@auto-trol.COM (Martin Brunecky) writes:
>     For your case I'd need a more generic one, specifying widget ID to
>     to set. Easy to do. I did not think of one, since to accomplish your 
>     task we have WsMatrixBox, which does all you need with 2-3 resources,
>     without all that ugly code.

I don't suppose WsMatrixBox is available anywhere?

>     With the X resource database, there is no problem, since the
>     "hidden" widget always has a name (somehow constructed by the
>     confusion routine). And since there is a name, and a known place
>     in widget hierarchy, you can define any resources you wish.
Ugh. Not your fault, but ugh nonetheless.

>>Incidentally.  OSF did at one point consider using an extended
>>Xresources form as an alternative to UIL, but was convinced (I forget
>>the exact reasons) that it wasn't appropriate (too hacky?).
>>
>     Wasn't the real reason some OSF member was already using UIL
>     and wanted to make it a "standard" ?

Keep in mind these are my opinions and mine alone, based on my view as
part of the team that "created" Motif.

There is no question in my mind that had OSF not chosen UIL, an "OSF
Member" would have been upset.  The results of that, I don't know - it
didn't come to that.  My feeling, and what I believe the consensus to
have been, was that UIL, while by no means perfect or even correct,
was a step in the right direction.  I also felt (and I regret not
examining the code more throughly in the hour or so I had it) that it
could be fixed, and that no better, timely (e.g. Open Dialogue was
potentially not timely (in retrospect I know that is wrong, it could
have been there, but...)), solution existed.  Given that something
like it seemed necessary, both as a transfer language for IDTs
(something the membership wanted), and as a means for supporting
internationalization, it was decided that it should be included but
not placed in the AES (Application Environment Specification) - in
other words, the specification of UIL is open for change in the
future. I, at least, was under the impression that work would begin to
correct these problems as soon as Motif was released.  In fact, there
were several possible approaches bandied about for what the new UIL
would look like and who would do the work.

In my opinion OSF dropped the ball here, and frankly I feel somewhat
betrayed, since what we worked out was a compromise and I feel it was
tossed as soon as the transition team left. I should point out
however, that I don't think, given my knowledge of the people who are
at OSF, that this was done for political reasons.  I suspect it has
been more a matter of manpower and priorities. I do think that it's
extremely regretable however, since the number of programs using UIL
is (as I was afraid) increasing rapidly, and any viable UIL
replacement now must support seamless translation to and from UIL
files.

								-kee
-- 
+-----------------------------------------------------------------------------+
| Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 |   Home: 617/641-3805   |
| 148 Scituate St.         | Smart fax, dial number. |                        |
| Arlington, MA 02174      | Dumb fax, dial number,  |   BBS:  617/641-3722   |
| nazgul@alphalpha.com     | wait for ring, press 3. |   300/1200/2400 baud   |
+-----------------------------------------------------------------------------+