🚀 go-pugleaf

In article <1991Mar21.100227.13538@convex.com> rosenkra@convex.com (William Rosencranz) writes:
>In article <2232@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito/) writes:
>>Installation scripts or programs could be distributed for each program 
>>that would automatically take care of unpacking, putting the binary,
>>the manual file and help file(s) in standardized directories, adding a
>>line to the desktop.inf so that double clicking a data file starts the
>>application, and...(do you want to add anything?)
>
>if you supply source (or even binaries) there is generally a makefile
>present. of course that assumes the installer has make and knows how
>to use it. make can very easily put things in the right place with
>relatively simple changes in the makefile, generally only 1 or 2 macros.

The problem is that I don't want users to have to know anything more
than how to double-click something to get started.  Expecting them
to have make, or to know how to use it is too much of an assumption.

In more detail: the user buys a disk or downloads a file.  He
double-clicks on that file.  It unpacks itself into the right
directories on the fixed disk and (optionally) starts up the 
application (ideally, for security reasons, access is restricted 
to the application as to which directories it can write to).  This is
done in a *standard* way so that once the user has installed one
application, he feels confident that he can install any product.
The application puts an icon on the desktop so that the user can start 
it up in the future (without actually having to know where it is 
stored).  To take it a step further, dropping the icon in the trash 
starts a deinstallation -- more than just the binary is deleted, an 
attempt is made to delete the files the application installed.  This way, 
the user only has to be familiar with the aspects of the program that 
are important to him, not what support files have to be in what 
directory and so on.

>just posted to comp.sources.unix is the purdue install system. i have
>not really looked at it yet, but it could probably be adapted for this
>use. think of this sort of program, universally accepted, as analogous
>to the patch program for updating source files.

If it isn't too huge, it may be worth looking into, thanks for the 
suggestion.

>a well written README should be all you need, but that can often[...]
The problem with README files is that you then have to figure out
where to store them, and unless you have a folder on your hard disk for
every little program you use (eek!) this gets to be a maintenance
problem.

>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.  

...
>of unix-like environments which have a well defined model. however, i like
>your ideas and may adopt some of them personally, since things seem well
>organized. good luck in your martyrdom :-(

Well, I didn't intend to _set_ a standard, just to open it up for
discussion.  Thanks for your compliments anyway...

>good luck. above all, keep thinking!
Uh, that will require a major effort on my part, but I'll try.  ;-)


plin
--
----- ---- --- -- ------ ---- --- -- - -  -  plinio@seas.ucla.edu 
This page intentionally left blank so that it could contradict itself.