Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!ncar!ico!auto-trol!marbru From: marbru@auto-trol.UUCP (Martin Brunecky) Newsgroups: comp.windows.x Subject: UIL or NOT to UIL Message-ID: <777@auto-trol.UUCP> Date: 14 Mar 90 01:00:31 GMT Reply-To: marbru@auto-trol.COM () Organization: Auto-trol Technology, Denver Lines: 207 A few weeks ago, comp.windows.x carried a discussion of the advantages and disadvantages of UIL. Some people suggested that UIL is essentially useless, that the X resource database is enough, while others have pointed out that there are things you cannot do with the database alone, such as definition of a widget tree, callbacks, compound strings etc. Prompted by this discussion, I have put together some code which, in my belief, extends the the X Resource Database so that an ENTIRE USER INTERFACE can be defined (and customized) within the database. This avoidins the need for multiple sources of user interface definition by replacing UIL. I am posting an overview of this "POOR MAN'S UIL" here to get some feedback on. If there is enough interest, I can post the code, which has been tested with Motif and other widgets on SPARC, Ultrix/RISC and VMS/VAX, on comp.sources.x. To start, let me present a simple example of an application-class X resource file for a Motif based HelloWorld: # # shell - an application shell, containing RowColumn organizer # HelloWorld.managed.child_0: box,xmRowColumn # # box - the main container, contains label and button # Helloworld.box.spacing: 8 HelloWorld.box.managed.child_0: label,xmLabel HelloWorld.box.managed.child_1: button,xmPushButton # # label # HelloWorld.box.label.labelString: Hello, WORLD ! # # button # HelloWorld.box.button.labelString: Push ME HelloWorld.box.button.activateCallback: push(Push again to EXIT) # Except for the top-level shell creation, there is NO widget creation code in my HelloWorld. The entire widget tree definition is shown above. For any widget, I can specify any number of children with all their resources, and all recursively. Callbacks are specified in a similar way, by passing a string argument as call data. Note the example is a starting point: It does NOT show all the functionality such as deffered subtree creation, manage/unmanage callbacks, etc... APPLICATION CODE IMPACT A runtime interpreter must be able to translate X resource database strings into widget classes (or widget creation routines), and callbacks. Even though some systems (VMS for example) allow dynamic binding, the current implementation uses registration routines: WsRegisterObjectClass ( app, "xmlabel", xmLabel ); WsRegisterObjectClass ( app, "xmpushbutton", xmPushButton ); WsRegisterConstructor ( app, "xmRowColumn", XmCreateRowColumn ); WsRegisterCallback ( app, "push", pushCB, NULL ); In environments supporting shareable images, all toolkit classes and constructors may be registered during toolkit initialization. To initiate creation of the widget tree from the definitions stored in the X resource database, an application must (either directly, or by means of a callback) invoke the routine: WsCreateXrmChildren ( widget ); WIDGET TREE CREATION MECHANISM The WsCreateXrmChildren routine scans the X resource database for widget subresources in the following format: path...widget.[un]managed.child_n: name,class[,nonrecursive] For each such subresource, the routine creates a child as specified by the name and object class (or the creation routine - constructor). Creation recursively descends the widget tree, unless stopped by "nonrecursive" option. The latter may be used to defer sub-tree creation, using a callback which invokes WsCreateXrmChildren (for example, WsCreateXrmChildrenCB). When a child is created, WsCreateXrmChildren checks the resource database for xrmCreateCallback resource for the child, and executes such callbacks if present. This mechanism allows the delivery of child's widget ID to other, already existing widgets (such as a Motif defaultButton resource in dialog boxes). CALLBACK STRING CONVERSION A string to callback converter is provided with the package. The converter builds an XtCallbackList using registered callback names. Any callback on the list may have an optional string argument. A pointer to the string is used as callback client data. If no argument (string) is provided, the default client data value provided at registration time is used. The callback resource specification in the X resource database has the following format: path...widget.callbackName: name[(args)][,name[(args)]]... where name is the callback name assigned by WsRegisterCallback, and args presents an arbitrary string. WIDGET TREE CONTROL CALLBACKS The package provides basic callbacks for widget tree control. The callbacks take a (list of) widget names as "client data". The widget name is qualified according to Xrm rules: box.label. The following is list of the provided callbacks: o CreateXrmChildrenCB ( widgetName, widgetname ...) creates children of the named widgets as specified in the X resource database o ManageNamedChildrenCB ( widgetName, widgetName ...) manages a (list of) named widget(s) o UnmanageNamedChildrenCB ( widgetName, widgetName, ... ) unmanages a (list of) named widget(s). o SetWidgetResourceCB ( resourceName, widgetname, ... ) sets the specified resource in a (list of) named widget(s) to the widget id of the widget invoking the callback. Consider the callbacks above as a starting point. More callbacks can be provided to control popup/popdown, to load additional resource files and much more. COMPARISON WITH UIL The X resource database user interface definition, here (for lack of better names) referred to as WsXc, performs essentialy the same function as UIL. A complete comparison with UIL can not be done without additional input. Here I try only to mention several important differences between UIL and WsXc. Implementation: A UIL application uses multiple user interface definition sources (application code, UIL file, compiled UID file and an X resource file). WsXc requires only application code and an X resource file, and the application code would be limited to callback functions. The UIL approach is based on a compiler generating intermediate code which is interpreted by Mrm at runtime. WsXc is purely a runtime interpreter. Performance: Since UIL uses pre-compiled, machine specific data, the widget tree creation should be faster than that for WsXc. However, even UIL widget creation accesses the X resource database for resources NOT explicitly specified by the UIL file. Since MOST resources are usually NOT explictly specified, the overhead depends more on the Xrm database volume, than on the widget creation method used. Preliminary experience with WsXc is favorable. However, final judgement requires much more experience than is currently available. Extensibility. Adding new widgets to UIL, even with the new Motif WML facility, is not an easy process. Adding new data types (resource representation types) to UIL is sometimes impossible. On the contarry, there is nothing special about adding additional widgets to WsXc. The same method also applies to adding new data types. The only requirement is the addition of a convertor from string to a particular data type. Syntax Checking: The UIL compiler can perform rigorous syntax checking for widget resources, thus assisting in user interface development. WsXc can not catch any syntax errors in resource pathname specification, such resources are simply ignored. However, errors in resource value specification can be caught by the resource converter. In addition, a simple tool that acquires a widget's resource list and performs X resource file syntax checking can be provided. Value Computations: The UIL compiler can compute the geometry of individual widgets using arbitrary arithmetic expressions. Geometry values in the X resource database can not, currently, contain expressions. But, since Xrm uses cpp, a string substitution could be applied. This limitation is a resource converter issue. A more intelligent string to integer converter could evaluate arithmetic expressions, including X resource database value substitution. Besides, geometry configuration should be left to the geometry manager widgets and not hardcoded. Resource Conversions: UIL supports resource conversions such as colors, pixelmaps and compound strings. Many of the conversions are performed at runtime, using resource converters, the same as WsXc. For some resources, such as Compound Strings, UIL compile time conversion provides some runtime savings. In addition, the current string to compound string resource converters are not intelligent enough to allow an unlimited compound string specification in an X resource file. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404