ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) (12/02/88)
This is a nice idea, but I'm starting to worry about the
proliferation of handlers, devices, and libraries. If
REXX: were to become standard, we would need to install
libs:arexx.library, l:rexx-handler, and the actuall AREXX
server itself (lives in c: I guess - I don't actually own
AREXX). This is not really a complaint about AREXX - rather,
I feel that the proliferation of support files makes things
confusing for inexperienced users. I've done a bunch of
thinking about how to automate the process of installing
and REMOVING software that requires support files - and I
haven't come up with anything worthwhile. Any thoughts?
For instance: J. Schmo, new Amiga owner, wants to use the
ARP command set. He's not a complete novice; he understands
the risks and advantages of using (relatively) unsupported
software; he just doesn't know about the details of the
thing - and shouldn't have to.
Similarly, there's no easy procedure for upgrading pre-existing
boot disks to 1.3. I don't know if the 1.3 enhancer manual
discusses it or not, but it's a tricky proposition for someone
who doesn't even know there IS a devs: or a l: directory,
let alone that some (but not all) of the contents of those
directories must be changed, and some should not (those
libraries, devices, etc. which are specific to the software
in question.)
- Ranjit
"Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!...
-- I'm not a drug enforcement agent, but I play one for TV --dbk@fbog.UUCP (Dave B. Kinzer @ Price Rd. GEG) (12/02/88)
In article <6457@netnews.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >This is a nice idea, but I'm starting to worry about the >proliferation of handlers, devices, and libraries. If [deletions many] >For instance: J. Schmo, new Amiga owner, wants to use the [more deletes] >who doesn't even know there IS a devs: or a l: directory, >let alone that some (but not all) of the contents of those >directories must be changed, and some should not (those >libraries, devices, etc. which are specific to the software >in question.) > > - Ranjit >"Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... > -- I'm not a drug enforcement agent, but I play one for TV -- Help for J. Schmo, new amiga user: While not specifically addressing Ranjit's questions, the idea of tieing multiple files to an icon hit me. I usually work in the cli environment, and I do not know a way to do this (maybe there already is :-)). This way, with a single drag, the novice user could move a program *plus* all it's associated files to another (possibly hard) disk. Maybe using the multiple tooltypes there could be additional entrys for other files for workbench to copy. (i.e. BOUNDFILE = datafile). Another way might be to tie the icon to a directory so the entire drawer is copied and adding a tooltype to select an executable in the drawer if it is double clicked on. (This could make entrys into next year's BKDC easier :^)) Some random thoughts by: | // You've heard of CATS and DOGS, I'm from GOATS, Dave Kinzer | | // Gladly Offering All Their Support! noao!nud!fbog!dbk | | \X/ "My employer's machine, my opinion." (602) 897-3085 |
peter@sugar.uu.net (Peter da Silva) (12/02/88)
In article <6457@netnews.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) writes: > This is a nice idea, but I'm starting to worry about the > proliferation of handlers, devices, and libraries. It's a problem. > I've done a bunch of > thinking about how to automate the process of installing > and REMOVING software that requires support files - and I > haven't come up with anything worthwhile. Any thoughts? Well, for devices a 'mountlist editor' that could also read the sample mountlist provided with each device and figure out where to put stuff would be workable. Some sort of generic installation tool that took a template file and handled the installation would help. Something like this (in a sort of RFC-822-like format): Title: Recoverable RAM Disk. Name: VD0: Type: device File: asdg.ramdisk.device; devs: Mountlist: { Device = asdg.vdisk.device Unit = 1 Flags = 0 Surfaces = 1 BlocksPerTrack = 16 Priority = 5 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 255 Buffers = 5 BufMemType = 5 } Multiple file: entries are possible. This should have enough info to install and de-install files. The tool that does the de-install should be able to tell (say) that two devices use the same handler and so it shouldn't remove the file unless both are removed. If these guys are stored in a file (s:templates?) with blank lines between them... Maybe they can be stored in mountlist itself as special comments? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
peter@sugar.uu.net (Peter da Silva) (12/03/88)
In article <1578@fbog.UUCP>, dbk@fbog.UUCP (Dave B. Kinzer @ Price Rd. GEG) writes: > Another way might be to tie the icon to a > directory so the entire drawer is copied and adding a tooltype to select an > executable in the drawer if it is double clicked on. (This could make entrys > into next year's BKDC easier :^)) This already works if the executable is a Workbench tool. I don't know if ICONX or XICON will work this way. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
gary@eddie.MIT.EDU (Gary Samad) (12/12/88)
In article <6457@netnews.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: }This is a nice idea, but I'm starting to worry about the }proliferation of handlers, devices, and libraries. If }REXX: were to become standard, we would need to install }libs:arexx.library, l:rexx-handler, and the actuall AREXX }server itself (lives in c: I guess - I don't actually own }AREXX). This is not really a complaint about AREXX - rather, }I feel that the proliferation of support files makes things }confusing for inexperienced users. I've done a bunch of }thinking about how to automate the process of installing }and REMOVING software that requires support files - and I }haven't come up with anything worthwhile. Any thoughts? I absolutely agree with you about this problem of complex installation procedures. Much as we hackers hate to believe it, more and more Amigas are being sold to simple users, not programmers (and the fate of the machine depends on it!). The majority of technical support calls that we get for our products (Microfiche Filer and Microfiche Filer Plus) are from users that want to solve a problem using their computer, use Workbench exclusively, and barely understand the concept of nested subdirectories, much less that some like devs: and libs: exist but are invisible! My opinion is that it is up to the software manufacturers to provide 1) a clear, printed description of the installation procedure, and 2) an icon that does ALL of the work for them! If a user can't even get the software installed easily, odds are that he will either put it back on his shelf, or worse, return it to the dealer, meaning another lost sale to the developer. ---Another pet peeve--- We've been getting a number of calls recently with people complaining about our software giving them a message on startup about a missing library. It turns out that a number of manufacturers are releasing software which includes the workbench, but are taking libraries (like mathieeedoubbas.library) out of libs: to save space. When the novice user then tries to run software which asks for this library, the user says "Wadda ya mean? I booted with a Workbench disk!" ---PLEASE include the FULL Workbench...or better yet, don't include the Workbench at all, but include an installation program for the user. (How many programs are still on the shelves with Workbench 1.2 on them?) Just my humble opinion, but based on direct experience... Gary