🚀 go-pugleaf

> 
> I do not claim first hand knowledge of this situation,  But somebody
> here (HP-corvallis) did look into the situation.  It turns out the
> defect is likely to be a design defect in the XGetDefault() library
> routine.  Here's what I've been told:
> 
> The XGetDefault() routine saves the first instance of the program
> argument.  Then XGetDefault uses this saved initial instance of your
> program name string for all subsequent calls.  [...]
> [...] you were locked out from calling XGetDefault() using any
> other program name.  This is clearly an example of a routine doing
> extra work that is not desirable.

I've looked into it too, and it doesn't work quite that way. What
happens is that the data base (/lib/X/Xdefaults, then ~/.Xdefaults) is
opened and read onthe *first* call to XGetDefaults. All lines
beginning with `.', or with the first string given (usually argv[0])
are read and put into a binary tree for subsequent searching. Thus,
subsequent calls do not re-read the database file, and are very fast
at finding the information, which is very good, but there is NO WAY to
re-open the file to get another database set with a different
identifier string. There is also no way (other than a symbolic link
ahead of time) to look anywhere besides ~/.Xdefaults or
/lib/X/Xdefaults. 

I believe the V11 resource manager addresses these problems. 
-- 

Bill    UUCP:  {seismo|ihnp4}!harvard!cfa!wyatt
Wyatt   ARPA:  wyatt@cfa.harvard.edu
         (or)  wyatt%cfa@harvard.harvard.edu
      BITNET:  wyatt@cfa2
        SPAN:  17410::wyatt   (this will change in June)