Concept

Similar to IKImageBrowserView, but supports arbitrary drawing via icon subclasses, and is compatible with 10.4. A single-column view that scales icons to fit containers is also available. The view scales to several thousand icons with no problem, and takes advantage of multiple processors/cores when possible. Memory usage for the framework should remain low.

Here's a screenshot of one of the SamplePrograms:

Supported File and URL Types

• PDF/PostScript
• Skim PDFD
• Anything NSAttributedString can read
• http/ftp URLs and local HTML files using WebView
• QuickTime movies
• Anything ImageIO can read
• Quick Look thumbnails (on 10.5)
• Icon Services as a last resort

Availability

Compilation currently requires 10.5, but could be accomplished on 10.4 with a modicum of effort. Copy enums and typedefs from Leopard headers as needed, or possibly from the latest QuickTime headers on 10.4.

Why Use This?

If you're only supporting Leopard, IKImageBrowserView is probably faster, and will likely improve in future. FileView is designed to be more flexible (icons scale as large or small as you need), and of course the source is available for modification. It was originally intended for use in BibDesk, so some of the functionality is problem-specific.

Code for dumpster-divers

• FVOperationQueue and FVOperation, similar to NSOperation
• priority queue with fast enumeration
• thread-safe disk cache for arbitrary data
• CGImage scaling with vImage
• Finder icon label control
• Malloc zone for reusing large blocks of memory
• Thread pooling
• demonstrates two-way view binding implementation
• demonstrates IBPlugin implementation
• demonstrates CFRunLoop sources

Any or all of these may be improved upon significantly, of course! Bug fixes and performance improvements are welcome, and feel free to e-mail with questions or comments.

API Documentation

There are only three public classes in the framework, but most of them are commented. See FrameworkDocumentation for a link to the Xcode docset.

Known Problems

• There are certainly bugs in the code, but I'm not aware of anything critical at this time.
• Apple's ATS code has a memory corruption bug or bugs that can cause a deadlock after it stomps on memory. FVCoreTextIcon seems to avoid this to some extent since it doesn't get the same font change notifications as the AppKit string drawing mechanism, but it's only available on 10.5. PDF files with embedded fonts are a likely culprit.
• Garbage collection is not supported, nor will it be supported unless someone volunteers to do it. With the present mix of Cocoa, CoreFoundation, and CoreGraphics using Obj-C, C, and C++, writing a dual-mode framework is outside the scope of a hobby project.

Users

Currently the only app using the framework is BibDesk as far as I know, which is using an older version with a bunch of local changes.

Support

Feel free to email with questions: amaxwell at mac dot com.