4526P@NAVPGS.BITNET (LT Scott A. Norton, USN) (12/18/86)
Ralph's idea to increase the use of icons in applications programs is right on the mark. To the people who say "But not every file has an icon," I reply "So who wants to access the file l/RAM-HANDLER or s/startup-sequence from an application?" Of course, system programmers use text editors to fiddle with characters, CLI to manipulate files, and other tools to carry out primitive operations. An application program should abstract these details out, and deal with the more ideal objects that icons represent. But how to do it? Ralph's idea, to use the mouse to pick icons out of workbench windows, confilicts with Intuition's use of these windows. ( And they are Intuition's windows. You pick in them, and Intuition, not the application program, gets the input. ) Also, these icons are not abstract enough. They represent disks, tools, projects, or drawers. Most applications programs will not want to access tools, and maybe not disks. Conversely, a disk program like DirUtil would only want to access disks. The menu philosophy says "only offer permitted choices." For example, The Workbench doesn't show a disk for df1: if there is no disk in that drive. To implement this type of interface, here's what you have to do. 1. Generate icons for the files ( Or other abstract objects ). 2. Somehow generate a list of these objects. 3. Pull their .info files off the disk and display them. 4. Respond to user "picks" of the icons. Step 2's statement, to generate a list, gives you a couple of design decisions. You could go with current hierarchy of drawers and projects, or you could do a recursive search of all directories and pull out the objects you want no matter where they are. Tracy Kidder, in The Soul of a New Machine, asked an EE about oscilloscopes and logic analyzers. The EE said, "Oscilloscopes are what cavemen used to troubleshoot fire." Filenames are the o-scopes of the Amiga. LT Scott A. Norton, USN Naval Postgraduate School Monterey, CA 93950-5018 4526p@NAVPGS.BITNET