diaz@venice.SEDD.TRW.COM (Phillip Diaz) (03/12/91)
Wcl users,
What would you consider as major selling points for using Wcl
over UIL ? Other than public domain software (broader range
of testing), smaller source code (?), access to Wcl source,
less internal declaratives for defining window displays,
and no cost.
Can you think of any others ?
Phil Diaz
pdiaz@oahu.sedd.trw.commarbru@attc.UUCP (Martin Brunecky) (03/14/91)
In article <1039@venice.SEDD.TRW.COM> diaz@venice.sedd.trw.com (Phillip Diaz) writes: >What would you consider as major selling points for using Wcl >over UIL ? Other than public domain software (broader range >of testing), smaller source code (?), access to Wcl source, >less internal declaratives for defining window displays, >and no cost. >Can you think of any others ? Without any particular order: - much, much, much smaller source code (-) - 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) - UI definition direct portability (no huge, binary .uid files) - ability to "wildcard" specifications: *background: brown - ability to specify resources for resource class, widget class - changing the UI definition in 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 .... and probably several more important ones, I just can't recall ... -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
gstiehl@convex.com (Greg Stiehl) (03/15/91)
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.
marbru@attc.UUCP (Martin Brunecky) (03/15/91)
In article <1991Mar14.164945.8074@convex.com> gstiehl@convex.com (Greg Stiehl) writes: >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. Agreed (though I consider it less anoying than a UIL compiler getting lost in the code where I forgot to type a semicolon after a brace: };. We'w been thinking about resource files "lint" for a while. The required Xrm interfaces, however, are not in R4. Bob Scheifler promises they will be in R5 - then we can do it. > >Another down side of not compiling Wcl is that you *have* to ship the user >interface description. > Not at all. Remeber you can load resource files at your will. If you want to hide your UI definition, you can ENCRYPT your resource files and decrypt them during the load - and your encryption does not have to be too fancy == costly. Similarly, people argue that the user can shoot himself by changing the resource file. Again, the application can force whatever resources are critical to it in so many ways ... > >> - 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. > The very first thing I did with WsXc 1.0 was a benchmark against UIL. To my surprize, Wcl was faster. It did not have to open and read those huge .uid files. Naturaly, your milage can/will vary. The Xrm database size is an issue, and I hope it willl be adressed by R5. However, the Xrm design is already doing lots to minimize an impact of a complex, deep Xrm database structure on widget creation. Besides, if you use resource files along with UIL, the same database search is used with UIL (plus the all .uid file processing). And you have to understand two concepts (UIL and Xrm), and maintain your UI component in two totally different files. Grrrrrr -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
XITIJSCH@DDATHD21.BITNET (03/16/91)
Martin Brunecky wrote: > Without any particular order: > > [...] > > - passing callback (client) data as strings (encourages pseudo-standard) > - natural extension of the X resource database: NO NEW LANGUAGE > - ease of learning the concept > .... and probably several more important ones, I just can't recall ... Just two questions: 1) Can you use a WCL specification as a template? I.e., I want to create more than one instance from a specification. 2) How do you pass non-strings as client data? E.g., an object pointer for a C++ member function dispatcher. -- Joachim ===================================================================== Joachim Schrod <xitijsch.ddathd21.bitnet> Technical University of Darmstadt FR Germany