korfhage@CS.UCLA.EDU (04/24/87)
We have some HP workstations here (300 series machines, I think. At least
that is what the boxes say) and I have been writing an X application using
the Xlib and Xrlib libraries. I would like to know if anyone else has
encountered a problem using XGetDefault() with Xrlib. It seems that
before calling XrInit() to initialize Xrlib, XGetDefault works as one would
expect. But after calling XrInit, XGetDefault always returns null, as if
it can't find the defaults. Anyone have any hints on this?
Willard Korfhage
ARPA : korfhage@ucla-ats.arpa or korfhage@cs.ucla.edu
UUCP : {ucbvax,ihnp4,randvax,trwrb!trwspp,ism780}!ucla-cs!korfhagegarfinke@hplabsc.UUCP (05/06/87)
> Speaking of Xrlib, is there going to be such a thing with V11 X? Where X goes, Xray will follow. > Will it be supported by HP? HP only supports Xray on HP computers (and only if you buy it from HP). The code on the X distribution tape is not supported by HP. (You get what you pay for). However, if someone else wants to get it off the distribution tape and support it for another computer, that's ok with us. It's just like X in that respect. > Will it continue to be in the public domain? I don't see why not, but I'm not the guy that makes those decisions :-) Dan Garfinkel, garfinkel@hplabs
ken@hpcvlo.UUCP (05/06/87)
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. YUK. What this means is that when you called XGetDefault() with the program name you then locked out the X-ray library from reading the x-ray defaults. Also if you called XrInit(), which calls XGetDefault() with a program name of x-ray, then 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. This also relates to a previous notes string where people discussed having many links to a program like xterm, and then having xterm call XGetDefault() using argv[0], thus a person could have many different names for xterm where each name would be bound to a different set of default values. It was then noted that there would be much duplication between default name sets and that the duplication could be elimated by having xterm first call XGetDefault() using argv[0], then if it found nothing to resort to a generic call using the a name like xterm. A sound idea. BUT as we see this will NOT work with the current implementation of XGetDefault(). PROPOSAL --> What is the chance of making the change to XGetDefault() for v11 to stop it from saving the first instance of the program name argument. We are all grown up programmers; If I give an argument to a library routine shouldn't it trust me to supply the argument of my choosing? Thanks for listening, and thanks for helping us note defects in the current offering. -Ken Bronstein hp-pcd!ken (503) 757-2000 X4133
jg@jumbo.dec.com (Jim Gettys) (05/07/87)
In article <3940010@hpcvlo.HP.COM> ken@hpcvlo.HP.COM (Ken Bronstein) writes: >PROPOSAL --> What is the chance of making the change to XGetDefault() >for v11 to stop it from saving the first instance of the program name >argument. We are all grown up programmers; If I give an argument to >a library routine shouldn't it trust me to supply the argument of my >choosing? The current intent is to reimplement the routine using the resource manager built for the X toolkit, which will be moved into the base X library as a result. The resource manager will also be used to remove the english language strings from the base library, to aid in internationalization. This work should be done by beta test of V11. This should fix the problem. Jim Gettys
wyatt@cfa.UUCP (05/08/87)
> > 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)