hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (04/21/87)
One thing I've noticed about Mac users is that they find the Desktop metaphor very useful. Something I HAVE noticed, however, is that the non-technical among them don't even know the Font/DA Mover exists, and they don't know how to handle fonts and desk accessories. There are advantages to this approach. Having lots of icons for all the fonts is probably too messy and not advantageous. In this case, you might want to have something like a Font/DA Mover (call it Font Mover.) This is simply because fonts really should be treated differently from support data directories or support libraries, in that any application can use them, and it is easier to perhaps manipulate a list of fonts in a Font Mover program than to move tens of little font icons around (although the font icons could be made to look like the font, which would be cute.) However, one can implement both strategies. For things like font management, you might want to implement something like a Font/DA Mover. For device drivers, libraries, printer drivers, data directories attached to an application, and so on (in particular the last use) you really want to use an attached-files icon approach. This approach has the advantage of using the same visual metaphor and reduces the amount of technical knowledge the user needs in order to play with his/her Amiga and configure it to his/her needs. I might be convinced that printer drivers should be put under the aegis of a Font/DA Mover, but this is not the way the Mac does it (there is a little icon for each printer driver in the System folder.) Also, the Workbench user who only uses one printer (I suspect this is the majority of users) could simply delete all the printer icons that s/he didn't need. I've already suggested a Device Manager or Device Mover should be implemented to allow the Workbench user to select which devices should be mounted or not. One small problem arises with vd0: and suchlike devices which must be mounted first, before other tasks have a chance to mess up memory; perhaps a special devices-to-be-mounted-at-startup list should be provided and scanned at startup. vd0: also needs to be polled, as in a DIR command or something-can this be worked around, Perry? Can vd0: be changed to wake up at Mounttime rather than at first poll? Perhaps the system software should initialize the device when it is mounted, rather than just adding it to the device list. Alternatively, a "prepend" function (i.e., prepend to startup-sequence) could be added (in addition to "append"). Of course, "prepend" is more messy and in general isn't what you want. So some sort of explicit system support for mounting and initializing devices on startup would be nice. -Mitsu
spencer@eris.BERKELEY.EDU (Randy Spencer) (04/24/87)
In article <1710@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes: > There are advantages to this approach. Having lots of >icons for all the fonts is probably too messy and not advantageous. >In this case, you might want to have something like a Font/DA Mover >(call it Font Mover.) This is simply because fonts really should >be treated differently from support data directories or support >libraries, in that any application can use them Now, it was my idea, but I like it. If you want to distribute a program for people to use in ANY configuration then you give them a Font Mover program and your executable will give an error message that tells them what it needs. There are only so many things that can be wrong. "I need pipe.device to be in devs:" Then the user whips out the Font Mover, opens sys: on one side, opens the distribution disk on the other side, and boom! it displays pipe.device as not being on the sys: disk. The user clicks and copies the file over. > > However, one can implement both strategies. For things like >font management, you might want to implement something like a Font/DA Mover. >For device drivers, libraries, printer drivers, data directories attached >to an application, and so on (in particular the last use) you really want >to use an attached-files icon approach. I think that using a Font/DA thingy would work better on all but the last one, and all you need to do to keep the data directories attached is a drawer! By putting the executable in a drawer (that also contains your non-iconified data files) you let the user move EVERYTHING at once, and that way the computer can always find the support files. (If you start from WB the CD will be the location of those files, and if you started from CLI you can find the path to them by editing out the command name from argv[0]. Maybe there is a better way to do it. I am talking about what to do Now. I am releasing software Today, how do I do it. Well, I give him a bootable disk and tell him what my program needs to run by giving him error messages when I don't find all my support files (libraries, and fonts, and devices...) Then I give him the power to create his own environment. Now, of course you could do it with an install script, maybe that is a good option, but that doesn't give the user as much control (and Joe User doesn't like running programs that write to his hard disk unless he knows what is being written, he is bound to feel more comfortable moving the files himself) > I might be convinced that printer drivers should >be put under the aegis of a Font/DA Mover, but this is not the way >the Mac does it (there is a little icon for each printer driver in >the System folder.) There are only two printers that can be used on the Mac, I don't think that they would ever make a printer mover for two printers. > -Mitsu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-