Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ames!elan!tom
From: tom@elan.Elan.COM (Thomas Smith)
Newsgroups: comp.windows.open-look
Subject: Re: re: Fallback Resources
Message-ID: <1017@elan.Elan.COM>
Date: 28 Jun 91 23:18:20 GMT
References: <2rasb54@openlook.Unify.Com>
Organization: Elan Computer Group, Inc., Mountain View, CA
Lines: 44

About the virtues/limitations of application-default files...

From article <2rasb54@openlook.Unify.Com>, by unknown@Unify.Com:
> From someone who's identity was omitted from the last posting:
>> I know i can do basically the same thing using an app-default
>> file but i would like it better if the information was
>> compiled into the program where it can't be lost ...
> 
> Sorry, I don't understand the concern people have when they
> fear an app-defaults file may be "lost". I usually retort,
> as I'm doing here, that one is just about as likely to lose the
> a.out (application) itself as an app-defaults file. Certainly
> losing the application (or the app-defaults file) is a bummer,
> but what is the likelihood? I think this is a non-issue, in
> practice, but I can't argue with the fact that people do
> worry.

When a user desides "I want to copy this application to another place,"
he or she usually thinks "...and the application is the thing that
runs when I type 'doit'."  There is no obvious connection between
the executable 'doit' and the app-defaults file
"/usr/lib/X11/app-defaults/Doit", unless the the user in question happens
to be an X programmer.

Thus, the user types "rcp doit othermachine:~/doit" and the app-defaults
file is "lost".  Not only easy to do, but a non-developer is not going
to figure out what the problem is without getting on the phone.  Not
only does it make your product lower-quality, but support people are
too expensive to have them fielding calls on such a trivial problem.
This could have been avoided with an adequately-designed interface
architecture.

Those of us developing commercial applications that are designed to be
easy to maintain and support, as well as easy to use, require tighter
control over the installation and configuration.  The Xt premise of
"make it user-configurable unless the programmer bends over backwards
to limit it" just gives us headaches - removing even the option to
"bend over backwards" costs us money, and forces us to turn elsewhere
for interface solutions.

    Thomas Smith
    Elan Computer Group, Inc.
    (415) 964-2200
    tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom