Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!ames!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: UIL or NOT to UIL
Message-ID: <792@auto-trol.UUCP>
Date: 21 Mar 90 20:58:52 GMT
References: <777@auto-trol.UUCP> <1990Mar19.161533.13651@alphalpha.com>
Reply-To: marbru@auto-trol.COM (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 83

In article <1990Mar19.161533.13651@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes:
>     In article <777@auto-trol.UUCP> marbru@auto-trol.COM () writes:
>>    definition by replacing UIL.  I am posting an overview of this "POOR
>>    MAN'S  UIL"  here  to  get  some  feedback.
>
>1)  The major thing which keeps me from totally dumping UIL is compound
>string support.  In fact however, UIL doesn't even provide the kind of
>support that I need ...(text deleted)... Presumbably
>you could do something like this in the Xresources file using some kind
>of character encoding for the international strings, and special escape
>sequences for program input strings, but I don't know how easy it would
>be, and it probably wouldn't be useful without a program to construct
>them.

    It can be character encoding, but it can be a message reference
    as well, where the string in X resource is just a reference to
    a compound string stored somewhere else, and (presumably) created
    with a (native language specific) compound string editor.
    The beauty of X resource converters is that they'r simple, and can
    be overloaded. Sure, it would be great to have a unified way of
    defining compound strings in X resource files, but it has to wait
    till we decide what a compound string is. Since I don't work for
    an OpenEverything-) company, I'v got to wait rather than set-up
    s standard.
    The entire Compound String can of worm is too big to be resolved
    overnight. And UIL definition has the same problem as any other
    programming language ( and X resource database ). Unless you assume
    UIL compilers working with "native" character set, i.e. Chinese
    editor, Chinese UIL compiler, you will always need some kind of
    character encoding.
>
>2) Consider the following (somewhat fragmented) XmForm code, how would
>your solution handle it.
>
>/*
> * The first issue here is that we have massive references to other
> * widgets.  That presumbably can be handled?
> */
>    ( ... code deleted ... )
>
     There is no problem defining existing widgets as resources to
     other widgets - just a string to widget converter. Sorry I did
     not mention one.

     The problem is what to do in cases like yours, where resources
     are not known until all involved widgets are created.
     For simple cases (such as a default button), I did provide
     WsSetWidgetResourceCB callback. This callback sets a specified
     resource of a specified widget to invoking widget's ID.

     For your case I'd need a more generic one, specifying widget ID to
     to set. Easy to do. I did not think of one, since to accomplish your 
     task we have WsMatrixBox, which does all you need with 2-3 resources,
     without all that ugly code.
     ( AttachedBox is not the best solution to the problem, in fact,
      I believe it discourages people from using and writing constraint 
      widgets ).
>/*
> * The second issue is with convenience routines which create widgets
> * behind your back.  Note here that the widget pointer I have to use
> * to set the constraint resources is a hidden parent of ScrollText.

     I have a very strong opinion about "confusion routines" which
     create widgets behind your back, but I can't post it here -).

     With the X resource database, there is no problem, since the
     "hidden" widget always has a name (somehow constructed by the
     confusion routine). And since there is a name, and a known place
     in widget hierarchy, you can define any resources you wish.

>
>Incidentally.  OSF did at one point consider using an extended
>Xresources form as an alternative to UIL, but was convinced (I forget
>the exact reasons) that it wasn't appropriate (too hacky?).
>
     Wasn't the real reason some OSF member was already using UIL
     and wanted to make it a "standard" ?

-- 
=*= 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