Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!mit-eddie!uw-beaver!ubc-cs!lowe
From: lowe@cs.ubc.ca (David Lowe)
Newsgroups: comp.windows.x
Subject: Wish list for R5
Message-ID: <9118@ubc-cs.UUCP>
Date: 12 Aug 90 22:18:20 GMT
Sender: news@cs.ubc.ca
Organization: University of British Columbia, Vancouver, B.C., Canada
Lines: 86

Re: wish list for R5

As someone who has just gone through the process of learning X as a user
and programmer, I believe one of the areas of X that most needs cleaning
up is the way that resources are handled.  I've taken a stab at suggesting
a better mechanism below.


1) From the user's point of view (which should of course be given the
top priority in design), the current resource mechanism is a total
mess.  They are expected to know about the widget structure of an
application and the internal widget names, they are supposed to be
able to imagine the global implications of wildcarded resource
specifications, there is no feedback given when a typo is made, and
of most importance there is no standard graphical interface for
editing resources and little chance that one could be developed
from the current mechanisms.

The solution seems quite obvious.  The application programmer should
be able to specify a set of external configuration parameters (with
names chosen to reflect the application).  There should be one
standard mechanism by which these parameters are given names, default
values, valid ranges, documentation, command line arguments, and any
values loaded from a user configuration file.  This would provide
the information needed for a standard graphical interface for the
user to edit these parameters.  There is no need for the vast majority
of resource specifications that can currently be made for each
application, many of which would break an application.  Instead of
being able to modify the color of every trivial component, it would
be much more useful to allow modification of the color of a few
semantically related interface components.


2) Most of the introductory books on X suggest that all resources
be specified in an application defaults file.  This seems like a
total loss.  The O'Reilly book on Intrinsics programming suggests
that this file be placed in /usr/lib/X11/app-defaults, and gives no
other way of loading it!  Where does that leave the 99% of users with
no root access?  I know that there is an environment variable that
can be set to point at another app-defaults directory, but this means
that anyone else who wants to run my program is now going to have to
first set an environment variable to point to my directory.  Putting
resource specifications in the application defaults file makes it
far more difficult to understand someone else's program, as you must
now try to match up the widget specifications in the code with
closely related specifications scattered around in a separate file
(the opposite of object-oriented programming?).

In fact, most of the sample code distributed with X seems to have
been written by people who understand these problems and they have
avoided using application defaults files.  Its mostly the unfortunate
new user who gets lead down this path.  The argument that different
sites could install different application defaults is asking for
trouble -- this means that the poor user will have no idea whether
the application conforms to standard documentation and will face
unknown behavior every time he or she remotely uses a client on a
different machine.  There is almost nothing about a "site" (i.e., NFS
file system) that makes it the appropriate unit for customization.


3) The code is far easier to understand and write when all the
resources are specified where the widget is created using the new
varargs interface.  Configurability could be supported by inserting
values at this point that depend on the external configuration
parameters described above.  Currently, the manuals describe at
least 4 or 5 different ways to set resources, indicating that none
of them is really satisfactory (but the varargs is the closest).
Success will have been achieved when the introductory manuals on
X have only a couple of pages on how to set resources instead of
several chapters.


4) These changes would allow a new name to be given to this capbility
for program configuration (e.g., "configuration files").  The word
"resource" makes no sense in this context and is already being
used for totally different mechanisms in X.


In summary, the current "resource" system should be replaced by a set of
programmer-specified configuration parameters.  A standard graphical
interface could then be written to allow the user to edit them.

-- David Lowe
   Computer Science Dept.
   Univ. of British Columbia
   lowe@cs.ubc.ca