Problems with XGetDefault() and Xrlib?
korf...@cs.ucla.edu
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 : korf...@ucla-ats.arpa or korf...@cs.ucla.edu
UUCP : {ucbvax,ihnp4,randvax,trwrb!trwspp,ism780}!ucla-cs!korfhage
garf...@hplabsc.uucp
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
k...@hpcvlo.uucp
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
Jim Gettys
>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
wy...@cfa.uucp
> 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
> [...] 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: wy...@cfa.harvard.edu
(or) wyatt%c...@harvard.harvard.edu
BITNET: wyatt@cfa2
SPAN: 17410::wyatt (this will change in June)
Mark Kernodle
Speaking of Xrlib, is there going to be such a thing with V11 X?
domain? Does it exist now?
We have a fair amount of stuff build on XRAY, and it appears that the
cutover to Xt is going to incur considerable rewrite, thus my concern.
Frank Hall
> Speaking of Xrlib, is there going to be such a thing with V11 X?
YES! We will be making our plans for X-ray more public in the coming months.
As we stated at the X conference in January, the X10R4 release of Xrlib was
the first phase of an ongoing development plan within HP for an X-based user
interface management system. That development is continuing in close
coordination with our work on the X Toolkit, and we expect to make significant
further results public this year. For a partial synopsis of our plans for
this phase, see the paper I gave at the X conference. These plans include
Xtlib-compatible callback functions, arglists, easier development of field
editors, and a simpler and more powerful panel manager. New messages will
be added where existing messages cannot be compatibly enhanced.
Our goal is to make X-ray easier and easier to use and more and more powerful,
while maintaining a stable, upwardly-compatible basis upon which our
customers, ourselves, and interested members of the X community can base
software development. We wish to help stimulate the formation of meaningful
ease-of-use software for the Un*x market.
Due to the necessities of timeliness, stability, and ease of customer
transition to V11, our current X-ray2 development is based on V10 and will be
available in that form. At that point X-ray programs will be able to talk
to both V10 and the new V11 servers (through V10->V11 Xlib and/or protocol
converter). This may not be available on the first V11 distribution (V11R0)
from MIT; depends on the timing.
In the X-ray3 phase, probably in 1988, we plan to use V11 and the X Toolkit
(which we expect to be sufficiently stable at that point) to greatly
increase the flexibility and power of the X-ray API.
Note that the purpose of X-ray is not the same as for Xtlib. Xtlib has a
goal of flexibility, at times at the expense of programmatic ease of use,
and a goal of remaining policy free. It is an API-implementer's toolkit,
which is not necessarily intended for use directly by the application
programmer. X-ray, on the other hand, is an API with the goal of simplifying
the application programmer's life by providing interactive gadgets with
a coordinated policy and appearance, accessed with a coherent programmatic
style, which are integrated into a user interface management system that
can evolve to support increased programmer productivity. We are adding
our planned X-ray2 features in such a manner that the X-ray API will be
efficient to implement and extend using Xtlib.
> Will it be supported by HP? Will it continue to be in the public
> domain? Does it exist now?
Yes, yes, and yes -- with clarification. Xrlib is and will continue to be
a supported HP product. HP has donated Xrlib to MIT for public use, but
does NOT provide support to the general public. Much of HP's X-ray-related
ongoing development will be open to public use, but some parts will stay
proprietary for a variety of reasons (licensing options may be available,
however). Since X-ray2 is V10-based and will talk to V11 servers by
compatibility paths, it DOES exist now (in as much as the compatibility
paths exist).
>
> We have a fair amount of stuff build on XRAY, and it appears that the
> cutover to Xt is going to incur considerable rewrite, thus my concern.
Our customers would have the same concerns, and we have to attend to our
customers. It took us a while to see how Xtlib and X11 were turning out --
X-ray3 was what we were hoping to do in the X-ray2 timeframe. We won't
satisfy those X-ray programmers (e.g., at universities) who may wish to
immediately use simultaneous X11 calls, or the neat flexibility of Xtlib,
but we have concluded that neither X11 or Xtlib are stable (or smoothly
evolutionary) enough to be a primary platform for our customer base in 1987.
It's easier to skate up a ramp than a staircase.
We'll publish more on our plans at a later date. We have an updated
Xrlib right now that adds some functionality to existing field editors,
fixes some bugs (including the XrInit/XGetDefaults conflict), our manual
with an expanded tutorial introduction, and a suite of tests for verifying
Xrlib ports, which we could make available to MIT for public distribution
if there is interest.
-- Frank Hall
hplabs!hp-pcd!frank