kempf@tci.bell-atl.com (Cory Kempf) (01/13/90)
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?
thanks in advance,
+C
--
Cory Kempf Technology Concepts phone: (508) 443-7311 x341
uucp: {anywhere}!uunet!tci!kempf, kempf@tci.bell-atl.com
DISCLAIMER: TCI is not responsible for my opinions, nor I for theirsmikey@portia.Stanford.EDU (Michael Yang) (01/14/90)
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). - M
flavio@mitisft.Convergent.COM (Flavio Rose) (01/17/90)
In article <553@tci.bell-atl.com>, kempf@tci.bell-atl.com (Cory Kempf)
asks whether it's good to use UIL.
The advantage of UIL is that it gives you considerable ability to
change the appearance of your application by changing the UIL file
and not the executable.
For example, if you are tweaking the position of a control within
a dialog box, it's easier to tweak it by recompiling a UIL file
repeatedly than by recompiling a C file repeatedly. UIL compiles
a lot faster than a C link/compile.
To give another example, if you are interested in having versions
of your software in foreign languages, you can put all the language-
specific stuff in the UIL file and use a single executable for all
languages. The same can be accomplished with message libraries, but
UIL files have the advantage that you can tweak dialog box geometries
to accomodate the fact that translated text can be longer or shorter
than the original.
The major con I've noticed is the extra size. Use of UIL without shared
widget libraries aggravates still further Motif's already notorious
memory performance problems. If you use UIL, your image will use
all the code that knows how to parse and load UID files. What is more,
your image is also going to reference all the widgets that UIL knows
about, even if your UIL files don't actually use them (because how does
the linker know you aren't going to use them? it can't go out and read
your UIL files). This can make your image much larger (depending on how
many widgets you would have used anyway and whether you've put the Motif
widgets in a shared library). mayer%hplnpm@HPLABS.HPL.HP.COM (Niels P. Mayer) (01/18/90)
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. *
anon@zip.eecs.umich.edu (Omar S. Juma) (01/19/90)
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...
blean@rwb.sgi.com (Bob Blean) (02/09/90)
> 1) A way to dump the complete set of resources from > an Xt based application. > 2) A WYSIWYG resource editor. HEAR! HEAR! These things are really needed if people who neither need to know not want to know about X stuff are to be comfortable with an X situation. X configuration today is NOT easy for most of the people we want to be using our computers. That has to change.
nazgul@alphalpha.com (Kee Hinckley) (02/19/90)
In article <1240@zip.eecs.umich.edu> anon@eecs.umich.edu (Omar S. Juma) writes: >In article <11658.632634712@hplnpm> mayer%hplnpm@HPLABS.HPL.HP.COM (Niels P. Mayer) writes: >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, Agreed. >* The UIL compiler does not invoke cpp before it starts its journey. Yo, DEC!!! Ah, the reason there is simple. VMS doesn't have cpp, and guess what group wrote UIL! > [Quiz of the decade: Where did DEC come up with 132? What, is it 128 and a bit?] Anything longer than that can't be printed on a line printer (remember those?). > 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 Remember, this is a presentation description language, not a dialog description language. UIL is a misnomer, and it is *not* a UIMS, and never claimed to be. My objection is that for such a simple language, it requires an incredible amount of syntax. By comparison the parser for Open Dialogue takes a much simpler, much easier to learn language, and does a lot more with it. > 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 We did, believe me we did. I was part of the team that chose Motif, and believe me I've regreted UIL from day one. We did consider Open Dialogue, and we did consider just taking the parser. In fact the informal agreement was that a preprocessor would be written that used Open Dialogue-like syntax on top of UIL, but evidentally that fell by the way-side. Open Dialogue had too main negatives, one was C++ (I know, it's there, I'm writing products in it, but the OSF Membership didn't think so), the other was that Open Dialogue wasn't using widgets. Yes it could be converted, but that gave people a bad impression. But anyway, believe me, the consideration was serious. > 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. I can't say anything about the deliberations (in fact, I've probably already said too much) but I know that *I* felt that with a new front-end UIL would be usable and useful. My disapointment is that OSF didn't devote the resources to do it, and that now it may be too late (unless someone puts one in the PD real soon). >* 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 Agreed, the UIL compiler is special-cased up the wahzoo. I tend to like your suggestion of starting all over again with a new compiler for the UID files, although I'm afraid it may be too much work. Putting a front-end on things at least gives some compability, although it does leave you with the back-end hacks. -kee -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | BBS: 617/641-3722 | | Arlington, MA 02174 | Dumb fax, dial number, | | | nazgul@alphalpha.com | wait for ring, press 3. | BBS line is still dead | +-----------------------------------------------------------------------------+
gjc@mitech.com (02/20/90)
In article <1990Feb18.175510.10634@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes: > In article <1240@zip.eecs.umich.edu> anon@eecs.umich.edu (Omar S. Juma) writes: >>In article <11658.632634712@hplnpm> mayer%hplnpm@HPLABS.HPL.HP.COM (Niels P. Mayer) writes: >>* The UIL compiler does not invoke cpp before it starts its journey. Yo, DEC!!! > > Ah, the reason there is simple. VMS doesn't have cpp, and guess what group wrote > UIL! Great, GUILT BY association. That is all you will get here because your FACTS ARE DEAD WRONG. Perhaps such ignorance would be forgivable if it wasn't so easy to get the correct information, $ HELP CC on any handy VMS machine tells you about $ CC/PREPROCESS_ONLY which is cpp under VMS. And if somebody really wants to use that to preprocess a UIL file then it is certainly easy have ones makefiles invoke it. -gjc
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (02/22/90)
In article <1990Feb18.175510.10634@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >I tend to like your suggestion of starting all over again with a new compiler >for the UID files, although I'm afraid it may be too much work. Putting a front-end >on things at least gives some compability, although it does leave you with >the back-end hacks. Why do you want a compiler that spits out a file that needs to be "interpreted" by the client-resident UIL code? Why not just have an interpreter? The Motif toolkit is more of an intepreter anyways in that it interactively responds to widget-object creations and messages sent to those objects. Until we have a toolkit that compiles into straight X11 code, I think that compiling into a UID file and then interpreting a UID file to create the widgets is a circuitous route to take when you can just specify the toolkit calls for widget creation and messaging in the first place. I said something to this effect in a previous note in this string, but nobody commented on the above assertion. WINTERP takes the interpretive approach hinted at above. If you prefer to have your description of widgets be hierarchical, or organized in a fashion that doesn't depend on the creation order and widget parentage, you can always write a parser (in XLISP) to read in the appropriate description and spit out "low level" winterp-lisp. The end result will still be readable and alterable, unlike a UID file. And of course, since the interpreter is always there, you can make interactive changes to the results of the "compiled" description too. [Note to DEC -- this is not a flame against UIL; it's an attempt at starting a technical discussion... so please don't forward this note on to my management in an attempt to "get me in trouble".] ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
marbru@auto-trol.UUCP (Martin Brunecky) (02/24/90)
In article <4855@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: >Until we have a toolkit that compiles into straight X11 code, I think that >.... > >I said something to this effect in a previous note in this string, but >nobody commented on the above assertion. > I did not comment assuming you are kidding ... (but aparently I have to learn something). So my widgets are NOT straight X11 code. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404