Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: System 5.0.4
Message-ID: <1991Mar8.052229.2372@nntp-server.caltech.edu>
Date: 8 Mar 91 05:22:29 GMT
References: <1991Mar4.051913.19742@world.std.com> <2441@ria.ccs.uwo.ca>
Organization: California Institute of Technology, Pasadena
Lines: 26

hackett@obelix.gaul.csd.uwo.ca (MICHAEL HACKETT) writes:

>  Something I'd like to see is having an
>icon resource that could be read by the Finder, though I expect this would
>slow things down too much.

Well, for applications and specific files that have unique icons this would
be a marvelous idea, because the finder wouldn't have to process their icons
every time it starts up or mounts a disk (the way it does now). The GS Resource
Manager uses a binary search to find specific resources, so the speed problem
would only exist with floppies. However, only the files with resource forks
would get scanned, and the files you'd want this feature for are going to have
resource forks anyway. Most data files and other files that use the standard
icon set are probably not going to have resource forks anyway. It still takes
time to figure out if a file has a resource fork or not, so here's a sneakier
scheme:

Finder's icons catalog has a new bit specifying 'I am only a generic icon'.
Icons with this bit cause the finder to look for an icon resource in files
on the Icon's type. We'll want to use the same convention the CDev.Init uses
so that CDevs will have their own icons too.

I think it's reasonable... any comments?

Todd Whitesel
toddpw @ tybalt.caltech.edu