🚀 go-pugleaf

plinio@crowe.seas.ucla.edu (Plinio Barbeito) writes:
>after i wrote:
>>i can propose another alternative: for those capable of running a binary
>>patch editor, building in patch space in internal path strings is easy:
>>
>>	char *path = "C:\\GEMPROG\\SUBDIR\\FILE.DAT\0                     ";
>>
>>then you can just hack in a new location (or better yet, provide a simple
>>tool to do it for the user.
>
>I think you've missed the point.  To make the ST truly user-friendly,
>the user shouldn't have to worry about any of this.  

yes, i agree in a perfect world you should never have to think about
the tools you are using. they should just automagically work. but in the
real world there are always trade-offs and restrictions. you have to
draw the line somewhere and make some assumptions, ALWAYS based on cost/
benefit (here cost can be development $$$ or time, generally the same
thing). general purpose computers are still not for everyone. it would
be nice to be able to walk into a room and say "computer: balance my
checkbook, then tell me if i am in trouble". right now, we have to deal
with files and less easy to use user interfaces. in 20 years we won't.
but we'll have other problems.

i have not missed the point. doing this and supplying an install program
(can even be inside the program) can patch these locations and the user
need only do it once. a well written program will manage this for the user.
the only assumptuion made is that users understand what folders are and that
they differ from files. and i don't see why it would be a problem to have
one folder per application either. less sophisticated users are not
going to have 2000 applications. more like 5 to 10. when they get to
20-30 applications, they are more sophisticated and you can expect them
to know more and ask more of them. i know you are really talking about
where to put things for each program. that means something like you
said: put all gem binaries in one place, put all rsc in one place, put
all readme/docs in one place. this may mean changing some file names
(there may be 150 README files). at the same time the true novice may
not know that app.prg is the program (.prg is a "standard" name) and
that gem programs generally have things called resources, .rsc (note
for nitpickers: i know there are lots of programs with imbedded resources
and in most cases, not all, this should be more common practice).
he only knows what s/he is told. it also means that the novice will have
to know more than you may think, organizational things. letting a
program do its thing as if it were the only program the user runs is
not necessarily bad, since there are users who only do word processing
or only play games or only DTP. there is a lot of bad software out
there. at the same time you really can't blame developers on the ST
for being sloppy. some stuff is ported from other platforms. and the
future of the ST is always debatable.

your proposal also means getting lots of developers
and perhaps atari behind this. i would not hold my breath. i don't think
there is a painless solution. i think your ideas are good, but i don't
think inertia can be overcome here. it appears that gem applications are
more like islands. this is not the case with unix where pipes and other
artifacts insure that applications work and play well with each other.

look, if i am meeting resistance to something as innocuous as "-help"
which is totally invisible, what makes you think 100's of developers
are going to adopt your scheme, no matter how reasonable/rational it is?
and for the record, i think it IS reasonable/rational. but the real issue
is promulgating a standard, not the technical details associated with it.
like most human endeavors, it is political. you have to deal with that
as well, considering what is the impact with and without said standard.

i did't realize how verbose i can get! sorry...

-bill
rosenkra@convex.com
--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com