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

(Courtesy of Donna Converse, converse@x.org; 1/8/94)
I advise using a site-wide application default file.

Advantages of using an application default file:

+ The site administrator can customize your application for all users
  at the site.

+ You can indicate in the application-defaults file which resources
  may be changed and the effect of changing them by commenting.

+ It's an additional form of documentation for power users of your app.
  Many users create an application-specific defaults file of their own.
  Those who do usually read the site-wide application defaults file
  in order to see what's going on.  To allow user-specified defaults
  to take precedence over site-wide defaults, application developers
  should always give the loosest resource binding and use class names
  rather than instance names where possible, in the site-wide defaults file.

+ You can supply multiple versions, each implementing different styles,
  languages, presentation arrangements, options, colors, demonstrating
  the coherence and adaptability of your application by having the user
  changing the value of their customization resource for your application.
  Application default files may include other application default files,
  making it possible to separate color customization from language
  customization, from functional customization, for example.


Disadvantages of using fallback resources for the default resources of
the application:

- Fallback resources were not designed with this purpose in mind.

- Code bloat.

- Users and site administrators will be tempted to edit your source
  in order to figure out what resources you have set and to make their
  own changes, making things messy and difficult for them when it
  comes time to update their sources.

- Anyone can override all of your default resources by supplying their
  own application default file, often inexplicably breaking your app.

- You're not taking advantage of one of the most powerful features of
  the X toolkit -- its provision for end-users to customize applications.


> I read where fallback
> resources should be a minimum to get the application running or to
> display an error if the application defaults cannot be loaded.  Any
> idea what a "minimum" is :-) ?

The X Consortium's mail application, xmh, has an application defaults
file aptly named Xmh.  If you remove this file, its fallback resources
are used.  In that case it pops up a dialog box warning you that the
application functionality will probably not work because the application
defaults file is missing.  This same design can be used as a versioning
check on the application defaults file, when one is used, and xmh implements
that as well -- so you can update your application and the app-defaults
file and implement a versioning check, and report it when the site
administrator failed to install your application correctly.

Now, try using the X Consortium's calculator application, xcalc, without
its application defaults file.  Nothing works at all, and, it doesn't say
why, so the application is worthless and uncommunicative without its
application defaults file.

So a minimum is to report that the application defaults file is missing,
or, if you have a simple application, to have the minimum functionality
in place with no decorative resources set.