MIT ATHENA WIDGETS
			------------------

This directory contains the code for all the Athena widgets.
I have converted all of them to VMS (except MAILBOX and VENDOR),
but cannot guarantee that they all work correctly.

There were three basic problems with the conversion:

	1. Under VAX-C, extern references are not picked
	up from an object library. globalref and globaldef
	must be used instead. The mixture of private and
	public .H files makes these changes non-trivial.
	Without these changes, toolkit applications must
	be explicitly linked against each object module
	that they require.

	2. Many of the Athena widget names conflict with
	the names of DECwindows widgets. This leads to the
	confusing situation where there are two variables
	with the same name, but different storage classes.
	This is easy to recognise, as you get a Toolkit
	error saying that you must have a non-null widget
	class when you try to run a program linked with the
	original Athena widgets.

	3. The VMS C compiler gets upset if the same 
	structure is declared extern and then initialised 
	in the one module.

The solution to the first problem is to change the way that
the widget record and class structures are declared. There 
is an include file called EXTERNAL.H which was my first 
attempt at a work-around, but I abandoned this once I realised
that it would not eliminate the need for #ifdefs in all the 
widgets anyway, because I had to change the widget names.

NOTE: The file EXTERNAL.H #defines externalref and externaldef
which are in the MIT Intrinsic.h, and also in the DECwindows
version of Intrinsic.h. It may therefore be better to use these
definitions for ALL widget record and class declarations rather
than directly using globalref and globaldef. However, this 
would not solve the second problem, which is the class names.

To eliminate the second problem, I added a prefix of "Xaw_" 
to all of the widgets. This has the unfortunate side effect 
that clients which use Athena widgets have to be modified to 
work on VMS. However, there is no other way around this.

I have not changed the names of any of the external routines 
in the widgets. Most start with "Xt", but in R4 they should 
all be changed to "Xaw". However, MIT does not currently 
intend to add a prefix to the widget classes.

The third problem was solved using #define to declare a symbol
inside each widget which indicates that it owns the widget
records, and the include files therefore do not make any
external references to them. This has no effect on clients who
wish to include the relevant public header files.

Finally, these widgets were designed for the R3 intrinsics,
and DEC only provides R2 under VMS V5.1. I am not sure how 
much effect this has, if any.


Known Problems
--------------

GRAYPIXMAP, which is not a widget, contains a routine which
is already in the DECwindows shareable image. This is probably
an oversight.

COMMAND was missing a parameter in two calls to HighlightRegion().
This caused some interesting behaviour because the widget worked
when compiled with /nooptimise! Presumably these are "known" bugs,
but I certainly did not know about them.

The COMMAND widget does not correctly redraw the text label when
it is resized, e.g. as in adjusting the grip in xcolors. It seems 
to rely on bit gravity, but in certain circumstances the text has 
been overwritten by the time that it is moved.

The LOAD widget is a fudge. It will not work correctly on a
multiprocessor system.

FORM does not work properly on VMS. The problem seems to be
that it assumes widgets will be properly placed (possibly by
the CONSTRAINT widget). As an example of the problem, see 
xclipboard, where the command and text widgets all overlap one 
another. (It does work on a Sun 386i though, so DECwindows is 
probably at fault.)

MAILBOX was not converted because it is specific to UNIX.

VENDOR will compile, but I have not used it because DEC also
provides a VENDOR widget.


	Trevor Taylor
	Oct-89