Path: utzoo!attcan!uunet!lll-winken!uwm.edu!cs.utexas.edu!usc!ucsd!ames!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: invalid resources
Message-ID: <773@auto-trol.UUCP>
Date: 30 Jul 90 15:28:41 GMT
References: <5677@hplabsz.HPL.HP.COM> <9007282124.AA00523@expire.lcs.mit.edu>
Reply-To: marbru@auto-trol.com (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 60

In article <9007282124.AA00523@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
>
>    I don't care about the IMPLEMENTATION issues involved in doing this.
>
>Then you are being unrealistic.  Efficiency (or lack thereof) of Xt-based
>toolkits is a major issue right now.  Performance is not to be dismissed
>lightly.
>
   I agree with both of you -). From an Xt user's point of view, (by the
   user I mean a programmer writing an Xt based application), the current
   behavior is highly undesirable. That is, using an invalid resource name
   in either XtCreateWidget or XtSetValue or XtGetValue does NOT produce
   any kind of feedback (except for that nothing happens).
   I agree with Bob that the area of widget creation is a highly sensitive
   one. One of the major Xt drawbacks today is that you cannot AFFORD to
   destroy and re-create widgets on fly - the overhead is intolerable,
   and thus we end up with huge, static widget trees, memory usage of
   which is again - intolerable. 

   From my knowledge of Xt internals I don't believe that penalty added
   by flagging argument list items as valid and checking for invalid at
   the end would be measurable.
   But, we can have it both - using an ennvironmental variable to turn
   argument list checking ON during development, and leave it OFF for
   production runs.
>
>    From an END-USERS PERSPECTIVE, it is unreasonable for no errors to be
>    reported when a user sets the wrong resource in an .Xdefaults, app-default
>    or xrdb file.
>
>This is a nice general statement to which I have a very hard time attaching
>any meaningful semantics.  For example, I have in my defaults file:
>	*ShapeStyle: Oval
>Should every widget in the universe that doesn't have such a resource go
>blatting out somewhere that I tried to set a bogus entry at creation time?
>You'll need to be much more precise about what your complaint is.
>
    Here you are touching my favorite one. What we need, is a LINT for
    X resource files. The primary problem with such a tool is that it
    needs to know the widget tree, not only the resources. That's why
    I am pushing the idea of having the widget tree definition contained
    WITHIN resource files, and NOT something separate such as UIL/UID crap.
    
    If you decide to use resource files to define BOTH your widget tree
    AND your resources ( such as done in WsXc or Mri contributions to
    comp.sources.x ), the idea of resource file LINT is quite feasible.

    Now, with resource file LINT you can specify what kind of checking
    you want. You may get a list of ALL the resources applicable to a
    given widget, or you can get a list of all widgets that understand
    a particular resource (or don't understand it) etc. You don't impose
    any performance penalty - you just use it when something is
    suspicious.


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