Linked List: September 21, 2009

Monday, 21 September 2009

Ross Carter on Snow Leopard’s Abandonment of Creator Codes ★

Ross Carter nails exactly what’s wrong with Snow Leopard’s abandonment of creator codes:

“For documents that are recognized by multiple apps, the user has the power to bind a particular document to any app they wish, using the file inspector in Finder. So at least for this purpose the creator code is not needed.”

Two words come to mind: puh leez. In what universe do people create a file and immediately, whistling with merriment, go to Finder and change the application binding for that document?

Snow Leopard Snubs Document Creator Codes ★

Speaking of TidBITs, Matt Neuburg had a great piece earlier this month on one of the few changes in Snow Leopard that I consider a turn for the worse: Snow Leopard now disregards creator codes when determining which app should open a particular file by default.

To be clear, the reason this change is problematic is not because the specific technology of type and creator codes has been abandoned, but rather that the functionality they provided is no longer available. If Apple wants to use UTIs or some other new metadata stash in place of 4-byte type and creator codes, that’s fine. The problem is they’ve abandoned them in Snow Leopard and replaced them with a system that doesn’t allow users to have, say, some text files open by default in BBEdit and others open in TextEdit, or some JPEGs to open by default in Preview and others in Acorn. The new system only “works” if you want all files of any particular type to open by default in the same app.

More Subtle Refinements in Snow Leopard ★

More Snow Leopard details from TidBITs.

How 1Password Injects Code Into 64-Bit Safari on Snow Leopard ★

Nice detective work by Kevin Ballard:

One of the big changes in Snow Leopard is the move to 64-bit applications system-wide. This includes Safari. Unfortunately, this change breaks all of the Safari plugins out there, including mine. There’s two reasons for this. The first is simply that these plugins are all 32-bit binaries, and a 64-bit app cannot load a 32-bit binary. The second, and significantly harder obstacle, is that the entire Input Manager mechanism has been eliminated in 64-bit apps.

The answer? They’re injecting code via a scripting addition — scripting additions being one of the few remaining plugin types that still load in 64-bit apps.

Larva Labs’s Concept Design for a New Android Home Screen ★

Interesting. More info here. (But they’re cheating a little by using Helvetica rather than Droid Sans.)