From: cek@sdc.boeing.com (Conrad Kimball)
Newsgroups: comp.windows.x,comp.windows.x.apps,comp.windows.open-look,comp.windows.x.motif
Subject: Re: X-GUI Builder Evaluations *********
Date: 8 Oct 92 17:59:36 GMT
Followup-To: comp.windows.x
Organization: Boeing Computer Services, Seattle, WA

In article <1992Oct5.195253.10473@jpl-devvax.jpl.nasa.gov>, parlier@jpl-devvax.jpl.nasa.gov (Randy Parlier) writes:
|> 
|> 	We are planning an evaluation on several GUI-Builders (XFacemaker,
|> 	UIM/X, BuilderXcessory, etc.) and would like to hear from anyone
|> 	out there that has recently done the same.  What products you
|> 	evaluated, what was your criteria, which "Builder" did you decide to
|> 	go with, and why, etc.
|> 
|> 	We would appreciate hearing from you.

Definitely take a good look at TeleUSE.  It's a complete user interface
management system (UIMS) rather than just an interactive design tool
(IDT).  This is important if, as I believe you should, you want to
continue to maintain your application using the same tools you used to
originally build it.  Most GUI builders seem to be basically
prototyping systems - use the GUI builder to build some window layouts
and some callback stubs, often with C and UIL code as the output, then
evolve the application from that point using traditional techniques.

It is difficult to determine from marketing information just how well
a particular GUI builder will serve throughout the lifecycle.  Often
the builder may make claims that are fine in principle but that simply
don't work out well in practice, and the builder ends up being used
simply as an IDT.

I've used TeleUSE for 2 years and wouldn't trade for any of the others.
Among my reasons:

- The dialog layer of the application can be written in an event-oriented
  language, "D", which interfaces very cleanly with C and/or C++ in the
  new 2.1 release.  Some claim "D" is a drawback, that they want all the
  widget callbacks to be in C, etc.  I disagree.
  
  - D is a higher-level language that makes it virtually painless to
    manipulate widget attributes.  The D code is compiled into C code
    which makes calls to TeleUSE libraries, and the C code is then
    compiled into object code.  Yes, you need TeleUSE runtime
    libraries.  But that's a problem with any GUI builder than provides
    "convenience" functions (e.g. UIM/X).  Additional runtime libraries
    are simply a price you pay for *any* higher-level language (even
    C++), and the tradeoff is a big win IMHO.  Also TeleUSE gives you
    the source code for their libraries.

  - D has a built-in event mechanism that lets you structure your
    entire application in an event-oriented fashion rather than a
    procedural fashion.  Yes, widget callbacks are an event mechanism
    even in C, but in D I can use events for other application purposes
    as well.  That is, in module A I can change some internal state
    condition then broadcast an event saying the state has changed.
    Any other module that is interested in that state change registers
    its interest and it gets control.  Any number of modules (zero or
    more) can express interest in an event, and each gets its chance to
    process the event.  In C module A would have to know 1) which other
    modules were interested in the state change; and 2) what specific
    procedures to call to process the state change.  An event mechanism
    is much cleaner.  If a new module is interested in the event, I
    never need to change module A.

    Events can be sent synchronously (a procedure call), asynchronously
    (queued and dispatched later when they reach the head of the queue,
    similar to X events received from the X server), or delayed
    (queued, with a specified minimum delay interval).  Widget
    callbacks can be traditional C language callbacks or D language
    (synchronous) events.

  - The TeleUSE interactive design tool lets you create templates,
    which are collections of one or more other instances of other
    templates or basic Motif or Athena widget classes.  A template is
    named and functions as a new class of object.  In a template you
    can hard-wire any widget resource that you don't want other coders
    or the user to be able to override (this is equivalent to setting
    the resource values via XtSetValues in the code), or you can set
    resource values that are merely nonstandard defaults and which are
    written to an application defaults file at build time.  If later on
    you want to change the template, the changes automatically propagate
    to all instances of that template.  Very object oriented...

--
Conrad Kimball		| Unix Server Tech Services, Boeing Computer Services
cek@sdc.boeing.com	| P.O. Box 24346, MS 7A-35
(206) 865-6410		| Seattle, WA  98124-0346
Newsgroups: comp.windows.x