Path: utzoo!news-server.csri.toronto.edu!rutgers!njin!paul.rutgers.edu!aramis.rutgers.edu!dimacs.rutgers.edu!bcm!convex!gstiehl
From: gstiehl@convex.com (Greg Stiehl)
Newsgroups: comp.windows.x
Subject: Re: Wcl vs. UIL
Message-ID: <1991Mar14.164945.8074@convex.com>
Date: 14 Mar 91 16:49:45 GMT
References: <1039@venice.SEDD.TRW.COM> <1237@attc.UUCP>
Sender: news@convex.com (news access account)
Distribution: usa
Organization: Convex Computer Corp, Graphics Software
Lines: 64
Nntp-Posting-Host: pixel.convex.com

marbru@auto-trol.UUCP (Martin Brunecky) writes:
> diaz@venice.sedd.trw.com (Phillip Diaz) writes:
>> What would you consider as major selling points for using Wcl
>> over UIL ?

Generally, Wcl is much better that UIL, but some important issues were missed
in Martin's list.

>    - much, much, much smaller source code (-)

Can't argue this one (except that Wcl offers me less job security :-)

>    - no need for a compiler (compiler maintenace on different platform)
>    - no need for a compiler (no compiler needed at customer site)
>    - no need for a compiler (no compilation step during development)

The UIL compiler adds a level of error checking that you can't get in
Xcl.  For instance, you could be setting the value of a resource that
doesn't exist.  While this isn't devistating, it can be very annoying.

Another down side of not compiling Wcl is that you *have* to ship the user
interface description.  Although I believe that the guts of a program
should be where the value is, some programs out there wouldn't be worth
much if they had to give away their slick user interface.

>    - UI definition direct portability (no huge, binary .uid files)

The argument to this *might* be that it costs you at run time, because
with Wcl the application has to read and parse the resource file(s) at
run time.  Whereas with UIL, the application reads in a binary file
that doen't need to be parsed.  Wcl also makes the Xt resource data
base larger, which could have adverse effect on all widget creations.

>    - ability to "wildcard" specifications: *background: brown
>    - ability to specify resources for resource class, widget class

You can still use resource files for specifing Xt resources.  You just
can't use it to create widget hierachies, callbacks, popups, etc...

>    - changing the UI definition in field by a simple patch to an ASCII file

The argument to this is that you can also break the UI in the field by
a simple patch to an ASCII file.

>    - natural extensibility (no extra affort to accomodate a new widget)
>    - passing callback (client) data as strings (encourages pseudo-standard)
>    - natural extension of the X resource database: NO NEW LANGUAGE
>    - ease of learning the concept

These are all very good arguments (if the list was ordered, these would
be at the top).  With the top one that was missed:

   - the ability to attach a "popup" action to widget event (i.e. activate).

This is by far the best thing about Wcl.  You can specify that when a button
is pressed, another widget (also defined in Wcl) is poped up.  This is some-
thing desparately needed by UIL.  I would use Wcl for this reason alone.

-greg.

----
Greg Stiehl (gstiehl@convex.com)
Graphics Software
Convex Computer Corp.