Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!sri-unix!hplabs!sdcrdcf!trwrb!cadovax!keithd From: keithd@cadovax.UUCP (Keith Doyle) Newsgroups: comp.sys.amiga Subject: Re: workbench Message-ID: <1318@cadovax.UUCP> Date: Mon, 12-Jan-87 14:57:05 EST Article-I.D.: cadovax.1318 Posted: Mon Jan 12 14:57:05 1987 Date-Received: Tue, 13-Jan-87 05:12:08 EST References: <1111@spice.cs.cmu.edu> <1394@umd5> <5394@ukma.ms.uky.csnet> <1986Dec24.191136.2866@utcs.uucp> Reply-To: keithd@cadovax.UUCP (Keith Doyle) Organization: Contel Business Systems, Torrance, CA Lines: 38 In article <1986Dec24.191136.2866@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >>In article <1394@umd5> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >>Why not just store the icon information in the original file? Having two >>files is awfully messy. > >Ah, but putting it in the same file is also messy. I think, in general, >one wants the icon (and other) information in the .info file to persist >even when an executable is replaced by the compiler, or a table is changed >by an editor. Stupid programs should be allowed to ignore .info files and >not break things. That's what's wrong with FILENOTE...no programs preserve >it, because none know it's there. There's an interesting idea, I wonder if you can append your file data to the end of a *.info file without confusing the system, i.e. will the workbench not try to read an entire 100k *.info file before displaying the icon etc. You could then write a word processor, or paint program or whatever, that saved all of its files with the .info portion as a header, while always keeping the .info at the end of the name. Would cut your directory list in half. Probably wouldn't speed up the workbench much though. While I'm here, I'd like to reiterate my position on this stuff: I don't spend much time in the workbench, I don't CARE much how fast icons appear. What I DO care about is how fast directory lists within applications appear, and how fast the CLI 'dir' command displays. The single 'icon' file approach would work only if all applications, such as DPaint, DMCS, Scribble, etc. etc. etc. read the single 'icon' file to get their directory lists, and kept the file updated. Well big news: they DON'T. I don't spend that much time on a workbench compared to how much time I spend in an application. If you can't either: 1) provide a fix that is transparent to the application, or 2) get all the applications writers to update their code to use a new scheme, then I think all this discussion about icon files is moot. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa