david@ics.COM (10/06/89)
UIL (both the DEC and the Motif flavors) does allow the user to add user-defined widgets. There is a fair amount of overhead in describing exactly which arguments, etc., the widget can take. This comment is based on close reading of the documentation. I haven't made sure that the supporting code works as advertised.
marbru@auto-trol.UUCP (Martin Brunecky) (10/10/89)
In article <8910061259.AA06690@ford-prefect.ics.com.ics.com> david@ics.COM writes: > >UIL (both the DEC and the Motif flavors) does allow the user to add >user-defined widgets. There is a fair amount of overhead in describing >exactly which arguments, etc., the widget can take. > I won't call it an overhead - you just must tell the UIL compiller what are your resource names, and (if used) provide symbolic names for constants, enumerations etc. Not bad. >This comment is based on close reading of the documentation. I haven't >made sure that the supporting code works as advertised. It really does work as advertised. Having currently over 10 widgets defined that way, all works O.K. From my viewpoint, the major UIL flaws are: - limited data semantics ( no structures, no arrays ...) - missing interface to user-written resource converters - missing conditional compilation (one must use C preprocessor explicitly) I can imagine anybody who used UIL can come up with at least 3 suggestions similar to my ones, and it may be an interesting contribution to those DEC and OSF/Motif guys working on UIL enhancements. However, my feeling is, that UIL is not the right solution. IF our systems had DYNAMIC (RUNTIME) BINDING (see OS-2 or Apollo Aegis), we could create the "UIL" using standard languages: C or C++, and still have all the benefits of separate user interface definition (without having to invent, stabilize and God forbid standardize a completely new language). -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru
gjc@eileen.mga.com (George J. Carrette) (10/11/89)
In article <320@auto-trol.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes:
However, my feeling is, that UIL is not the right solution. IF our systems
had DYNAMIC (RUNTIME) BINDING (see OS-2 or Apollo Aegis), we could create
the "UIL" using standard languages: C or C++, and still have all the benefits
of separate user interface definition (without having to invent, stabilize
and God forbid standardize a completely new language).
--
But UIL is NOT A PROCEDURAL PROGRAMMING language. It is just a description
of data. If you wanted to have data like that part of your program and you
wanted dynamic linking in a STANDARD LANGUAGE then your only choice would
be ANSI COMMON-LISP (if they ever complete the thing).
A big advantage of a non-procedural or descriptive language like UIL is
that it makes it easier to have a UIL generation program that can
write *and* read UIL files and edit them in a graphical manner.
-gjcmhn@hpfcdc.HP.COM (Mark Notess) (10/17/89)
> . The Ohio State "build a telephone" test using the Next IB was completed > in comparable time ( < 1 hour) using UIMX. I'm curious--what is this test? Can you give me a pointer to it? Is it some sort of UIMS benchmark? Mark Notess mhn%hpfcla@hplabs.HP.COM