To: xpert@expo.lcs.mit.edu
Subject: Re: To UIL or not to UIL? 
Date: Wed, 17 Jan 90 19:51:52 PST
From: Niels P. Mayer <mayer%hplnpm@hplabs.hpl.hp.com>

mikey@portia.Stanford.EDU (Michael Yang) writes:

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

	-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

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

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?

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

Date: 27 Mar 90 13:36:06 GMT
From: 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...

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