🚀 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.  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