----------------------------------------------------------------------

(Courtesy of Donna Converse, converse@x.org; 12/7/93)
See the R5 Intrinsics specification section 2.3 "Loading the 
Resource Database".   

Colors cannot be reliably specified in fallback resources.  The
only way you could force this to work would be to include in the
application the same algorithm that Xt uses to determine the display;
to open that display, determine if it is color, close the display;
and then set the appropriate fallback resources; and continue on
as usual.

The intended use of fallback resources is to provide a minimal number
of resources that will make the application usable (or at least terminate
with helpful diagnostic messages) when some problem exists in finding and 
loading the application class defaults file.

The application class defaults file is authored by the application
developer and can be used to specify default colors that apply only
to capable monitors.  

In addition, users of an Xt-based application can specify colors in
an application-specific user-specific resource file and have those
apply only to capable monitors.  The mechanism for setting this up
is introduced in R5 Xt and it is the customization resource and this
is noted in the Xt specification section 13.3.3.  Read that section,
read section 2.3, and look at this simple example for an application
whose class name is "Xmh".  (Maybe there's a tutorial about this
in one of the O'Reilly books?  Maybe I should write a book?)

The end-user must set the customization resource, at any point
earlier than when the Intrinsics goes to look for the application
defaults files.

#ifdef COLOR
Xmh.customization: -color
#endif

The application programmer supplies two application class defaults
files, and one has the string "-color" appended to the application
class name as the name of the file.  This file includes the other
file, and it also gives resources specific to color displays.  The
other file gives resources that generally apply.  

In the application class defaults file named "Xmh-color", it might say:

#include "Xmh"
xmh*borderColor: Red
xmh*background:	 Ivory

and so on.  In the application class defaults file named "Xmh"
it might say:

! AppDefaultsVersion should only be defined in the site-wide file
Xmh.AppDefaultsVersion:		1
Xmh.Geometry:			508x750
Xmh.ReplyInsertFilter:		cat
Xmh.SendBreakWidth:		2000

and so on.  The first line is a comment, and introduces another 
interesting mechanism that demonstrates how fallback resources 
can be useful in checking that the application class defaults file
is installed.  Xt will use the fallback resources only if the
application class (site-wide) defaults file is not found.  The
application itself, in this case xmh, checks the value of application
resource AppDefaultsVersion and if it is the default value, or of a
revision earlier than the application expects, it can recognize
that the correct default resources are not available and report it by 
popping up a dialog box with a message so the user can understand
what needs to be done to get these default resources.

The application class default files were intended to be modifiable by
a site administrator -- if you try to stuff all the default resources
into the fallback resources not only will you not have the power of the
customization resource but you might also have to tell people to edit
the source to change the default resources -- which is a disadvantage.