CocoaDust

I appear as a guest discussing Search Kit, the framework for indexing and searching files and text on episode 14 of the Late Night Cocoa podcast, out now.For anyone who doesn’t know, Late Night Cocoa looks at a different topic every week with a guest developer and is suitable for both novice and experienced Cocoa developers. It stands out because its host, Steve Scott, aka Scotty, does an excellent job producing a podcast that is not only useful and informative but also sounds good too. A lot of work goes in behind the scenes to make that happen.And, as always with a podcast, you can listen to what you want when it suits you, so if one topic doesn’t interest you, there are bound to be plenty more that do. So, check it out.

In this Ars post on Leopard’s ship date (I’m pretty sure it will be around WWDC, BTW), the paragraph that gets the most attention in the comments is this one:

One more tip we got regarding Leopard, is that InputManager plugins are no longer allowed. That’s right… no more little hacks from anybody besides Apple. No more Apple menu hacks. No more Safari plugins. (InputManager is not exactly the same as APE, by the way.) “Apple isn’t really broken up about it since InputManagers were often used for nefarious purposes anyway,” our sources said, but the loss of InputManager control will break a lot of shareware and commercial software that currently makes use of that control.

I have to say, this will be a huge help to me. The trouble with Input Managers is that they load into every application, and the problem with that is, they are almost always involved in the crash reports I receive for KIT. The telltale sign is when the crash is happening entirely in Apple code, sometimes drawing standard widgets, sometimes just as part of the run loop, with the Input Managers listed below.

The trouble is that KIT gets the blame. I’m not sure why KIT is so susceptible to these, as Feeder hardly seems to get affected, but I suspect it’s for a combination of reasons.

Firstly, the sort of people who use apps use KIT like the enhancements these Input Managers provide. Secondly, KIT uses a whole heap of Apple frameworks and is always swapping views in and out. Finally, KIT is very multithreaded, scanning for changes to files, indexing, searching, etc. Maybe some of the problems are due to the way KIT is designed, but I have no way of finding out.

I have no issue with people running Input Managers, as long as they accept that this means their set up is unsupported when crashes occur.

The simple fact is the application works perfectly on a regular system and I can’t fix problems in code that aren’t mine, so less hour spent sifting through crash reports that have nothing to do with me, the better.

One of the interesting things about Spotlight is that it only works on individual files. When it sees that a file has changed on disk, it uses the relevant importer to update the metadata store.

For each time it is called, a Spotlight importer can only provide data for a single item that will be shown in Spotlight’s results. A different approach is required for multiple items, such as bookmarks in your web browser or iCal events, that are contained in a database or single file (including file packages, because Spotlight won’t index the files inside).

It’s a very simple workaround, but seems a little clumsy, considering. Every time such an item is changed, you need to change a file on disk that can trigger Spotlight to invoke the appropriate importer.

To use iCal as an example, in ~/Library/Caches/Metadata, you’ll see a number of folders for different applications, including iCal itself. Looking in that folder, you’ll see a number of other folders with UUID-style file names that refer to the calendars in the application, and in those folders various files with .icalevent or .icaltodo extensions. These files contain data that the iCal importer will use to provide metadata to Spotlight. It’s iCal’s responsibility to ensure those files are created, updated and deleted as necessary.

In some cases, looking at files in the Metadata folder can reveal an surprising amount of duplicate data, with files filled with text. This is probably because it would be too much of an overhead, or too difficult for the importer to extract the actual data from the database.

If you’re designing a new application that uses a database or single-file format to contain multiple items that you want indexed by Spotlight, you should bear this in mind.