Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!ukc!harrier.ukc.ac.uk!rlh2
From: rlh2@ukc.ac.uk (Richard Hesketh)
Newsgroups: comp.windows.x
Subject: Re:  Programs relying on app-defaults files
Message-ID: <1242@harrier.ukc.ac.uk>
Date: 23 May 89 10:18:00 GMT
Reply-To: rlh2@ukc.ac.uk (Richard Hesketh)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 51

There is a confusion in the documentation as to the purpose of application
contexts.  This I believe is being changed in R4 8-).

App-defaults files are very useful and should be used by all non-trivial
X Toolkit applications, if only in the development stage.  I agree that
a program is not well designed if it *demands* the user to have defaults set
in his user defaults file(s).  Any required resource values should be placed
in an app-defaults file held in a common place .. /usr/lib/X11/app-defaults
and in places explicitly specified by the user.

The resource mechanism was designed to allow local customizations to be
made to programs without having to recompile them.  You must remember that
by setting resource values in an application using XtSetArg() lists that
you are removing the ability to change these resources in app-defaults files,
user defaults files AND via the -xrm command line option.  Do you really
want that??  What about allowing simple things like changing colours or
fonts?

I don't see that the one-file-per-application argument holds.  There are a
lot of applications which rely on special files being in the right place
and if the program comes with an installation script or at the very least
a manual page I don't see a great problem.  It is certainly not an argument
for dropping the use of resource files.

What you need .. is a method for allowing programmers to specify a
defaults file within the application program .. possibly in a statically
initialized structure.  These would be operationally equivalent to the
app-defaults file and would be merged into the resource database created
whenever a new application shell is created.  This would still allow the
external app-defaults files to override these values but would also
provide suitable defaults if the file was missing.  Also any resource
values set using the XtSetArg/Values method would still be hard-wired in
so that resources the programmer doesn't want the user to ever change
can be set.

In this way those who feel that every application should be only one binary
and no trailing files, and those who wish to make their applications
customizable by users would be catered for.  I personally don't think the
change is necessary, unless I am missing something very important here?

I am afraid I have to disagree with Erik van der Poel, you *can* have
separate app-defaults files for each new XtAppCreateShell(), as well as
the one specified in XtInitialize() and they do work.

Richard


Richard Hesketh   :   rlh2@ukc.ac.uk    ..!mcvax!ukc!rlh2
---                                               
Computing Lab., University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, United Kingdom.         Tel: (0227) 764000 ext. 3682