From: dage@ecrc.de (Dageville Benoit)
Subject: Re: X-GUI Builder Evaluations *********
Organization: European Computer-Industry Research Centre GmbH, Munich, Germany
Date: Thu, 15 Oct 1992 12:08:27 GMT

In article <7067@fury.BOEING.COM>, cek@sdc.boeing.com (Conrad Kimball) writes:
> 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

-- 


                                                  Benoit
Newsgroups: comp.windows.x