William M. Perry wrote:
> > Whatever we decide, we should keep in mind that these
libraries are
> > intended to be installed by copying over the real libraries. So it
> > would be real nice if xemacs did something reasonable (crashing is not
> > reasonable):
> >
> > - if built on a system with athena3d libs, run on a system with athena.
> > - if built on a system with athena, run on a system with athena3d.
>
> How do you intend that this is to be achieved?
>
> AFAICT, the Xaw* library which XEmacs uses at run-time has to have the
> same structure layouts as the Xaw* header files with which it was
> built. I don't see any way around this.
If that is the case, then the Xaw replacement libraries have failed
miserably, and are effectively useless. :( If they have been changing the
_public_ structures, that is very very bad. That is why everything is
split into different header files like Label.h and LabelP.h. Changing
LabelP.h should be kosher, but Label.h should never change.
Not quite.
Applications don't access Widget structures directly, but use
XtSetValues etc, which use the data in the XtResource structures to
locate the fields of the Widget structure.
OTOH, Widget methods access the fields directly.
The result is that you can change the private headers as much as you
like without having any impact upon APPLICATIONS which USE the Athena
widgets. However, any SUBCLASSES of the Athena widgets have to be
compiled using the correct header files.
Anyone who suggests that Xaw3d, XawXpm, NeXTaw etc should be installed
over the vanilla Xaw libraries either:
a) isn't aware of the above issue, or
b) assumes that nothing is going to create subclasses of the Athena
widgets.
This assumption is false in the case of XEmacs.
--
Glynn Clements <glynn(a)sensei.co.uk>