c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) (02/23/88)
On the issue of a SINGLE .INFO file to speed up the Workbench, which for some reason I opposed: > Actually, that is exactly the *right* solution. >If it weren't for the fact that all those .icon files clutter up my >directories, I would actually use the workbench. Putting the icons in >a single file fixes all the delay problems, makes the directories >quite a bit cleaner, and certainly does not make it anymore difficult >to manipulate them. > Also, such a file need not be large at all, since you only >need to keep one image for the N icons that use that image. Manipulation >is not difficult either. The workbench would handle all manipulation, >and have additional commands to create/delete/modify icons and bind >them to files manually. It would automatically delete icons for >files which have been deleted manually, etc..... > -Matt >No matter how fast, having hundreds of .info files is slower than a single >".icons" file. A single file is EXACTLY the right solution. Fast read >even on the old slow file system, small size, low overhead, no clutter. > Bryce Nesbitt I don't know what came over me. Too much formal training. You are both right. It is ludicrous to have a dozen or more icon files each taking up the minimum file size (1 block) and making an awful mess of directories. But how, then, could you copy a file AND ITS ICON from the CLI? Maybe make an "icopy" program that updates the icon files in the source and destination directories? Also, I have been frustrated with the incompatibilities between IFF and icon formats. Since "we" are changing the icon format already, why not make it a pseudo/real IFF file with several brushes? There could be one single "icon-editor" program that could just import IFF brushes. (FORM STAK, FORM TOOL, etc.) I have an idea. Change the WB "info" program so you can edit the icon within it. Get- and PutWBObject() or whatever could easily be modified to accept the new format. Combined with the fast file system, the new Workbench would be pretty zippy, instead of scaring off potential buyers of the machine. Scene: A computer store lucky enough to sell the Amiga. Imagine opening the window of a 80-meg hard disk on the Workbench - even if you have only 20 files in the root directory, the eyes of the man in the grey suit, and maybe he in the blue jeans, will stray across the room to the Mac II - or worse. The Amiga - superfast graphics engine, did you say? So how about it, Commodore? Face it - would you open a WB drawer on a television ad? *&(Jonathan Dubman)
jesup@pawl21.pawl.rpi.edu (Randell E. Jesup) (02/25/88)
In article <944@pasteur.Berkeley.Edu> c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) writes: >I don't know what came over me. Too much formal training. You are both >right. It is ludicrous to have a dozen or more icon files each taking up the >minimum file size (1 block) and making an awful mess of directories. >But how, then, could you copy a file AND ITS ICON from the CLI? >Maybe make an "icopy" program that updates the icon files >in the source and destination directories? ... > *&(Jonathan Dubman) Actually, the CLI version of copy should do (at least optionally) a GetDiskObject, and if one exists (non-default, if you have them) PutDiskOb- ject it in the destination directory. That would reduce the divergence between CLI and WB. Likewise Delete should remove it if it exists. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup