jrb@salina.UUCP (Jason R. Bova) (05/31/91)
Introduction:
In our quest for developing X clients for execution on SuperComputers
we want to isolate error messages for each layer of the X Window system.
We are using the big three X toolkits [i.e. ATT/OpenLook, OSF/Motif, and
MIT/Athena] and would probably like to have X Widget error messages as well.
We can write our own error handlers for this ... but, I was wondering if X11R5
will have Xt toolkit and Xaw widget layer error messages? We will probably
be using X11R5 [Xt/Xlib] on our SuperComputer and the R5 versions of the Widget
sets [Xol/Xm/Xaw] when they come out as well.
Also, we will want our X clients [executing from our SuperComputer] to be
able to come up on the widest variety of X Servers. One of the issues we will
have to deal with is the keyboard bindings for our applications. It seems
that OSF gives you a bindings directory with Motif meta key bindings files
[for their cut/paste, etc. operations] that are server specific. Will we have
to ship out server specific bindings for the universe of X servers out there
in order for our application's keyboard operations to work properly? Or, can
we create a universal keyboard bindings file? In ATT OpenLook one needs to
change the information in their property sheet pages for the keyboard bindings.
Are there any other work arounds for this? How does the mapping from keysyms
to keycodes get by the TM when there may be servers out there that it doesn't
recognize all of that servers keys? Is that what the XKeysymDB file was intended
to deal with? Will the "xmodmap" client work on servers like that?
Now, on with the reason for this posting... We are currently using X11R4.18
from ICS. Does anyone know where to get official MIT X11R4 XtErrorDB and
XKeysymDB files? They didn't come with ICS X11R4.
XtErrorDB:
We have this reference in $(ROOT)/src/lib/Xt/IntrinsicI.h
1 /*
2 * $XConsortium: IntrinsicI.h,v 1.42 90/07/26 10:05:52 swick Exp $
3 * $oHeader: IntrinsicI.h,v 1.5 88/08/31 16:21:08 asente Exp $
4 */
:
174 #ifndef ERRORDB
175 #define ERRORDB "/usr/lib/X11/XtErrorDB"
^^
176 #endif
Is this a copy of the /usr/lib/X11/XErrorDB file?
Or, is there another file for this somewhere that will
show Xt error messages as well? We only have the file
that is in lib/X11 called XErrorDB. What about Widget
set error databases? Will there be: XawErrorDB,
XmErrorDB, XolErrorDB files some day? Is there a PD set
of X Error handlers out there that can help track this?
Or are errors only interesting to track down at the X
Protocol level? I know the word "error" here probably
has a floating definition!
XKeysymDB:
What about XKeysymDB? It is referenced in $(ROOT)/src/lib/X/XStrKeysym.c.
We are currently using the one OSF Motif V1.1.1 gives you. Is there a universal
XKeysymDB file out there? I don't think the MIT X clients need it.. none of them
have complained about it not being there. Is the XKeysymDB file server specific?
It looks like it maps keysyms to keycodes. [i.e. the Motif version in the Xm
lib dir has the following lines at the end of the file:
:
! DEC specific keysyms
!
DRemove :1000FF00
Does this have anything to do with the ".motifbind" file you get
with Motif V1.1 in the bindings directory? Will this change for X11R5?
I thought I read some proposals about issues related to this somewhere..
Thanks,
Jason R. Bova
Super Computer Systems Inc.
uunet!ssi!jrbswick@athena.mit.EDU (Ralph Swick) (05/31/91)
175 #define ERRORDB "/usr/lib/X11/XtErrorDB"
Is this a copy of the /usr/lib/X11/XErrorDB file?
Or, is there another file for this somewhere that will
show Xt error messages as well?
The XtErrorDB is supposed to be in the same format as the XErrorDB
but the contents are completely different. We (MIT) have never
actually created or shipped this file (an oversight). The closest
thing that exists, short of extracting from the Xt sources directly,
is Appendix D of the Xt spec.
What about Widget
set error databases?
A fine idea. Contributions gratefully accepted :-)
Note that unless you actually modify the text of an error message
there's little point in having an additional file; you'll just use
more memory at run-time.