🚀 go-pugleaf

    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