Snow Leopard’s Creator-Code Snubbing Now Official
In my article “Snow Leopard Snubs Document Creator Codes” (6 September 2009), I described, and discussed the implications of, a change in Snow Leopard’s Launch Services behavior, where double-clicking a document in the Finder ignores the creator code metadata signifying what application the document belongs to. I also complained that this change had been instituted surreptitiously, with no notification in any official Apple documentation.
Well, now the change is official. A sharp-eyed TidBITS reader has pointed out that in a recent revision (17 November 2009) of its Launch Services documentation, Apple explicitly calls out the change in a boxed note:
Note: In Mac OS X version 10.6 and later, Launch Services no longer considers file creator signatures when binding documents to applications. Launch Services ignores the creator signature when it’s attached to a document. In addition, the functions LSCopyKindStringForTypeInfo and LSGetApplicationForInfo ignore the parameter containing the creator signature.
And in a later boxed note on the same page:
Note: Criterion 4a [i.e. the conflict-resolution rule that gives primacy to a document’s creator code, if it has one] does not apply in Mac OS X version 10.6 and later.
Although this merely confirms what was already known by experience and experimentation, and although it has no bearing whatever on the question of the advisability of this change, it’s nice to see Apple come clean at last and state the facts plainly, albeit more than two months after Snow Leopard’s release.
This is a real problem.
this was one of the advantages of the Mac OS.
Absolutely agree. I miss this feature.
Apple should at least have allowed creator-code as a non-selected preference in the Snow Leopard Finder. As things are now, it's a HUGE drawback for any professional use, i.e. for using one app (or more) to edit files of a certain kind (BBEdit for html comes to mind), and another app (or more) to view them. This is bad.
Gruber has the best description of this 80s behavior: C:\ONGRTLNS.OSX (http://daringfireball.net/2009/10/congrtlns-osx)
We need a real and proper fix for the Finder, a hack, whatever, that does NOT touch the filesystem but brings back the correct behavior.
I understand that this is a problem in a general way. Can anyone explain why this is a Bad Thing for Apple and users?
Sure, here's a summary of something that has been possible in Mac OS since at least version 6.
I have a lot of .html file son my computer. Some are saved from Safari, but some are files I created in BBEdit. Before 10.6 the files I created in BBEdit would open in BBEdit and the files I saved from Safari would open in Safari. Now, I have to either set the application for every file individually, or I have to choose ONE application to open ALL .html files.
There is no way to duplicate the behavior of Mac OS 10.5 or earlier in 10.6. Some of us are losing a lot of functionality.
I understand this, but I'm just not sure it's a big issue, overall? It seems to me the traditional behavior was just as often an obstacle as it was preferable, depending on a person's needs.
For example, I often do some quick photo editing and resizing before uploading them to web sites. I tend to use GraphicsConverter for that, but I don't necessarily want each JPG image to decide GraphicsConverter is the new default program to open them with. So the *new* behavior is better for me, in this case. I can safely launch GC and do quick resizes on images without disturbing the default program they open with otherwise.
Programs like GC that are often used to do such quick and dirty work usually have a preference checkbox that turns off creator code assignment for apps of this vintage. For GC, as an example, the Save->Settings pane gives a radio button list giving total control. Most Cocoa apps don't even set a signature in the first place, since it required an explicit Carbon call to assign the signature. Even Carbon apps weren't required to set one (they could just pass "????" to the file creation/saving call) and were originally expected to not change a pre-existing code.
OS X era apps have entry options for "viewer" and "editor" assignment of these codes (and what was supposed to replace them) in their Info.plist files in their bundles, but Apple never got around to finishing the Finder's behavior to acknowledge these settings. Hence, the current controversy and pushback... (This problem alone is why I haven't installed 10.6 yet on my Mac, despite having the install CD for months now.)
Here's a quick and dirty example: Let's say I have Adobe Acrobat Pro installed. I probably want all the files it creates to open with Acrobat Pro, rather than Preview. However, there's no reason for me to load up Adobe's bloatware to view a PDF I grabbed off the internet. With the old functionality, the Adobe PDFs would be automatically opened with Acrobat, and the internet PDFs could be opened with Preview.
It's sorta convoluted but it's very frustrating to those who relied on this function of OS X.
Not true. If BBEdit wants the files it creates to open by default in BBEdit, it can explicitly set "default application", you don't have to do this manually. BBEdit can do this using a call to AppleScript to tell "System Events" to set "default application". This is a standard way to avoid making users do things manually.
Specifically, it's bad from a workflow perspective.
Another example is you make a 12 megapixel master JPEG with your camera, and a 320x240 throwaway JPEG by dragging a photo out of your browser. Totally different files.
The worst part is computer science nerds were prioritized over creative nerds. F**k that. This is the Mac, not Linux.
We now know that creator codes are not coming back, OK.
The real question is what can be done to replace the lost functionality. I tried Snow Leopard on an external drive, but decided not to install until the lost functionality was somehow fixed.
You'll be waiting a long time. Is it really that important a feature for you?
The convergence between Apple and Microsoft goes ahead to the lowest common denominator.
I have this problem with Excel files (I have hundreds of .xls files). Plain icon and double-clicking causes Excel to crash -- it has become a right royal PITA.
For those who might like a work-around, I've released SLopen which sets the opening app to the app that corresponds to a file's creator code. Yes you can do this already by hand but if you have a lot of files, SLopen can help you automate this process. It has a "test mode" so you can preview changes before applying them. See the website for more info.
Thank you for this.
This is 4 the n00bs! Apple wants the Windows users that are ditching XP and worried about 7. Snow leopard is pretty and fuzzy and opens the same kind of documents in the same application. I don't think this is lowest common denominator behavior at all. This is the polite behavior of polite software. All the complaints so far have been from computer literate people who are perfectly capable of using something like Vincent's solution above. Apple is after the illiterate and that makes perfect sense. The computer illiterati are tired of the technical hurdles that Microsoft makes them jump through. KISS is an Apple mantra and they're sticking to it. Good for them.
I understand Apple's desire to ditch the old creator codes, but to stop half-way and not replace them with a modern solution is ludicrous.
I've been running 10.6 for a few weeks now and haven't run into many problems related to this since I rarely open files from Finder, but rather from within applications.
Expect more 3rd-party solutions to become available. The rebuild of the Finder was a good first step, but they really need to improve its general file management features and functionality.
Hear, hear! Very short-sighted, and also sneaky. A very bad combination.
I hated that behavior, I hated that much that I never opened files with double click since system 8. Now in 10.6 I'm getting used to open images, pdf's and html files with double click because I know that they are going to be open in Preview and Safari. A lot more consisted, if you asked me.
Is this the reason why when I save a Filemaker file to idisk and then try to open it on another of my computers, it opens with Text Edit. I have to instruct it using get info to open it with Filemaker. This happens with every file and that's a royal pain. Is there no way to overcome this problem?
Juan, if you wanted all files of a particular suffix to open in a particular app, that was always possible. Just use Get Info on one of them, set your pref in the "Open with:" box and check the "Apply All..." button.
What we're complaining about is that that kind of solution means absolutely EVERY file with that SUFFIX gets opened by that ONE app. That's perfectly fine if you always use that ONE APP to create AND USE that file SUFFIX. It is not handy if you use many aps that can CREATE a file SUFFIX (text,html,rtf,xml,xml,jpeg,tiff,etc.) but want to be able to use the app that CREATED them when they are DOUBLE-CLICKED.
Of course, one cam always use the right-click and select an alternative app. Or use an apps Navigation dialog to select the file. Or drag the file onto a specific apps icon. But all those solutions require more than on step, multiple windows or possibly very long mouse movements.
And, as was said earlier, this was unique to the Mac! Now it's go. Sad, IMHO. :)
Maybe only a partial solution, but developers may use Uniform Type Identifiers ( UTIs ) in the info.plist for the app. I don't know if the 10.6 Finder honors this since I'm sill on 10.5.8.
UTI's are not a solution since an application cannot claim an existing UTI for an existing file format. You can use UTI's to associate the .footer extension with your app, but you cannot replace the functionality of creator codes for a png file with a UTI.
Yes, thus my use of the word "partial".
To quote Apple's developer docs( Uniform Type Identifier Concepts ):
"...you can define your own UTIs for application-specific use. For example, if your application uses a special document format, you can declare a UTI for it.
This is royal pain with no gain for users. I would love to see TidBITS conduct a survey on this issue and submit the findings to Apple.
Just one more example of how I found out about this new 'feature'.
I'm using large MS Word documents (Office 2004 .doc) that include indices (indexes). A while back I Dclicked one and panicked when all my indexing codes were GONE! No index markers and not index.
Text edit did me the 'favor' of opening it.
I subsequently changed the default for .doc to MS Word, but that is not convenient b/c most of the time I just want to open a file for a quick read, and loading MS Word is more than needed (and slow on 10.6 and Office 2004!).
A major WAAA if you ask me.