🚀 go-pugleaf

In article <9111210308.AA03917@ifsrad> greg@vis.UUCP writes:
>Let me know if this has already been discussed...
>
>The GNU options conventions and the GNU getopt function are an
>improvement over the old AT&T provisions but are primitive compared to
>the standard X-Windows intrinsics mechanisms which can be seen as a
>generalization of the GNU provisions.  Since many GNU programs will
>use X and most users will use GNU through X there would be an
>advantage in GNU programs using X resources.  I'll outline the X
>approach and then make some more detailed suggestions for GNU.
>
>[stuff deleted]
>
>MY POINTS
>
>There is nothing in all of these X resource manager mechanisms that is
>specific to graphic or GUI programs, so these mechanisms might as well
>be available to all programs.  Not only does this increase the
>sophistication of all programs but it simplifies things for the use
>since s/he will not have to learn two mechanisms.
>
>MY PROPOSAL
>
>As it stands, if you want to take advantage of the X resource manager
>you have to link with all of the X libraries.  I propose that GNU
>getopt be replaced as soon as possible with a version of
>XtAppInitialize that does not require all of the other X and Xt
>overhead.  I propose that GNU's argument handling conventions be
>replaced with the X conventions.
>
>Comments?

I like the idea a lot... I've always thought that the lack of standart
in that direction was one of the weakest points in the user interface
of any Unix-like system out there.

I also have another idea to add... I guess I should also post this
to an X-oriented newsgroup, but I'll take the opportunity to test
the waters here first.

While X resources are a great idea the biggest problem I've had with
them is the question of where to store them.  /usr/lib/X11/app-defaults
is the standart place, but what do you do when you have to programs with
the same name in different places in your directory hierarchy?  And 
having the resource files all in one central place isn't that great
anyway -- you open up most of the problems that people have with man
pages.

The ideal would be to keep the resources with the program... kind of
like on the Macintosh.  But *nix filesystems don't have a built-in
provision for that... (in fact, another major weakness of these OSes,
IMHO, is that they don't allow enough auxuilliary information for
files).  So do what CAP (Columbia Appletalk Package for *nix) does
with Mac files: store the resources in a subdirectory of the dir-
ectory containing the program which is called ".resources" in files
with names identical of those of the programs the resources belong
to.  Then modify "cp", "mv", "rm", and "ln" to take an option which
makes them automatically look for a ".resource" directory and per-
form the appropriate action on the resources belong to a program 
when the program is copied/moved/deleted/linked.

This idea can be extended to man pages and other information that's
auxilliary to the main program file.

Comments?
-- 
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629