Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!wagner From: wagner@utcs.UUCP Newsgroups: comp.sys.amiga Subject: Re: statement Message-ID: <1986Dec26.114028.13245@utcs.uucp> Date: Fri, 26-Dec-86 11:40:28 EST Article-I.D.: utcs.1986Dec26.114028.13245 Posted: Fri Dec 26 11:40:28 1986 Date-Received: Fri, 26-Dec-86 18:42:28 EST References: <1107@spice.cs.cmu.edu> <1986Dec20.144752.5348@utcs.uucp> <1278@cadovax.UUCP> <1767@sunybcs.UUCP> Reply-To: wagner@utcs.UUCP (Michael Wagner) Organization: University of Toronto Computing Services, general purpose UNIX Lines: 76 Checksum: 53954 I dont think I like the way INEWS does this...so let me provide my own introduction to the cast of characters. >>> is me (original article) >> is keithd@cadovax.UUCP (Keith Doyle) > is jmpiazza@gort.UUCP (Joseph M. Piazza) (no introduction) is me again (remember me?) >>>... I would like to have two icons that point to the same >>>executable or tool, with perhaps different options set (i.e. they differ >>>only in the parameters stored in the .info file). I don't think this is >>>possible in the current scheme. Anyone know how to do this currently? >> >>This sounds like a great idea. Can the Mac do this? I don't know. I've never had a Mac. Anyone know the answer? > The Amiga does already. Take a look at the Amiga Basic demos. Each >has it's own icon and yet they all point to the Amiga Basic tool. Seems to me >that the wheel has already been invented. :-) Um....that's not what I said. Or, at least, that's not what I meant to say. I guess I wasn't very clear. Let me try again. There is already a kind of shorthand implicit in .info files (thank god). First of all, a little terminology. Programs are TOOLS in the workbench. Files that you feed to a program are called PROJECTS. These include BASIC programs, input to word processors, music processors, etc. The .info file for a TOOL points to the program involved. The .info file for a PROJECT points to the input file AND the TOOL that should, by default, process it (other TOOLs can be selected by the user, but lets not diverge here). Several PROJECTs can select the same TOOL. This is the 'shorthand' that is refered to above. I said 'thank god' because otherwise you would have to have a seperate copy of the BASIC interpreter on disk for every BASIC program. My suggestion was that a TOOL (or a PROJECT, for that matter) might have two ICONS (and two .info files), corresponding to different invocation options. For instance, I could have two ICONS, called UNIX and CMS, both of which called up Dave Wecker's VT100 program, but passed it different initialization parameters, so that one called my favorite UNIX system, and one called my favorite CMS system. So, I want Icontype.info Corresponding TOOL Initializer TOOL CMS SYS:c/vt100 CMSinit TOOL UNIX SYS:c/vt100 UNIXinit TOOL PRINTIT SYS:c/vt100 PrettyPrintCMS Notice that the tool isn't called the same thing as the .info file. Notice that .info files point to the same tool. The tool isn't even in the same directory as the .info file. Why is this useful? Suppose I have several uses for a tool like VT100. Sometimes, I converse with UNIX, and I know that I'm using VT100. Sometimes, I converse with CMS. I'd like to call them different things, since the environments look so very different. Sometimes, I want to print a file on the laser printer at work. I have to call it something else...conceptually, it's completely different! But they're all still the VT100 program. The PRINTIT ICON calls up VT100 in script mode, calls work, signs on to CMS, runs KERMIT, sends the file to CMS, has it printed, deletes it from the file system, and signs off. The PRINTIT ICON shouldn't need to have another copy of VT100 attached to it, duplicating all that disk space, just so the user can have a more descriptive name for it! Moreover, I might have PRINTIT ICONS in several different drawers. They may print to different standards (because the drawers are used for different things). I want to be able to run programs out of different drawers, or perhaps in the default PATH (does the workbench implement PATH-like concepts?). Hmmm...I think this is getting too long...I'll stop here. Michael