🚀 go-pugleaf

In article <132@ra.abo.fi>, rosenber@ra.abo.fi (Robin Rosenberg INF) writes:
>Bryan suggests we use a 'mountlist' to install programs. I suggest a
>'make-file' instad.
>Why a makefile then? The problem is that sometimes when you are about to
>do something you have to do something
>else first. ...

Good idea!  Actually, the two formats could be merged very easily.  For
example, say program 'blah' depends on program 'blee' to be run first:

blah: blee
	<parameters>
#

blee:
	<parameters>
#

This way the 'Start' program could figure out dependencies and run programs
in the right order.  The main difference would be, with this, ALL listed
programs will get run, while with Makefiles, only ones that depend
(directly or indirectly) on the first one will get run.  In other words,
the dependencies only tell the *order* in which things get run, not whether
or not to run the programs.

As I said before, this would not be good for a do-it-all, highly
customizible startup sequence (we already have one of those, the
Startup-Sequence).  However, it would provide an easy way to install and
run programs without making the user do lots of work.

Another option would be to do something like Commodore did with the
'Expansion' directory.  Just have a 'Startup' directory, and a program
similar to BindDrivers that would find all the icons in this directory and
run the programs as necessary.  This way, a user could 'install' a program
by simply dragging the icon into the 'Startup' directory, and all the
parameters could be in the .info file.

>ISSUE#2: Setting program parameters.
>Programs that have parameters to change should have an intuition program to
>to that. The program should be callable from the main preferences program
>so we can set *all* parameters from essentially the same place. The preferences
>program could store the parameters in the makefile along with the rules
>for running the program. 

Another good idea!  How about this.  Each (conforming) program would
include a separate setup program (with its own icon) that the user just
drags into the Prefs directory.  The main Preferences program would search
the directory for other icons and put them in a menu, and when the user
activates one of the menus, Preferences simply boots the program like a
normal Workbench program.  That way the user could activate that particular
setup program directly as well, by clicking on its icon from Workbench.

ISSUE#3: 'Assign's
Lots of programs require their own 'assign'ed directories, and, like
startup-sequences, these work only from the CLI.  How about using Dave
Haynie's BindNames program?  The program's install or setup program could
simply write all required assigns (relative to a directory specified by
the user) to its own 'names' file in the SYS:Names directory.  Since
BindNames automatically goes through every file in the SYS:Names directory,
this would be quite simple.  Also, an icon for the Names directory and for
the program's 'names' file would be good, so the user could delete the
thing if and when he deletes the program itself.

				Bryan

--

     ____________________________________________
   _/ Bryan Ford - bryan@geo-works.geo-works.com \_
 _/    ..!utah-cs!caeco!i-core!geo-works!bryan     \_
/   ..!uunet!iconsys!caeco!i-core!geo-works!bryan    \