Snow Leopard Snubs Document Creator Codes 214
adamengst writes "In this TidBITS article, Matt Neuburg explores how Mac OS X 10.6 Snow Leopard changes how the operating system handles preferred application bindings, dropping support for the creator codes that have been part of the Mac OS from the early days. He also explains how to work around the problem, if you want, for instance, text documents created with BBEdit to open in BBEdit even when TextEdit is the default handler for text files."
quicktime (Score:5, Informative)
The editing features are now limited to trimming for example, the export possibilities rudimentary.
Fortunately, one can still reinstall Quicktime 7 additionally in Snow Leopard, but one can not change the default application binding for Quicktime. This is a serious problem.
For me, Quicktime pro is half the reason to use a Mac. Changes like this from Leopard to Snow leopard always make me nervous and I'm glad to have Linux catching up. Even apple might screw things up in future, possibly due to pressure of the movie and music industry.
One can for example suspect that the lack of cut and paste ability or export of sound only etc is due to such industry pressure. The average user can no more cut out advertisements for example. I do not see any technical reason why the new limitations are in place if quicktime pro is ditched. An other reason for the current limitations could be that a new QT pro is in the making. I hope this is the case. Still, one should be able to change the default application binding to an old version of quicktime!
Re:We Know Best (Score:4, Informative)
It's the developer, not the end user, that applies the creator code that's being ignored (I can't remember the last time I manually changed a creator code--it was long before OS X, anyway). The end user can always do a "Get Info" to change the default app for any individual document.
That said, I agree that it's a pain to have to do that for every specific document you want opened with a particular app; I just saw a nit that needed picking.
Re:Problem? (Score:3, Informative)
What if you didn't have OO.o OR Office installed?
Type/creator codes were meant to replace "ugly" extensions, but in the Internet age, the only way to pass file metadata around is in the filename - MIME types get preserved, if you're lucky, but more often than not, the MIME type is just based on the filename (i.e., the extension).
This was probably due to limited namespace - what is a ".doc" file? These days, it's 95% certainty it's a MS Word document. But it can also be a plain text file since many older programs from the 80s/90s used ".doc" to represent a generic document, like a manual. You'd have README, README.TXT, README.DOC, etc.
So Mac came up with a way to use 2 32-bit identifiers - a creator code, and a type code. Creators are used to identify a creator, so double-clicking would open the same app that opened it (back in the days when compatibility was horrible, the general thinking is you want to open something in the app that created it). The type ID was a fallback in case you can't find the creator, you can try a type lookup, in case it was something another program could handle. If not, you could consult a small database of creator codes to application name mapping, and display an error like "The file 'my file.doc' could not be opened because 'Microsoft Word' was not found, nor any other program that could open it.", thus providing the user with a reason why the file can't be displayed/viewed/etc., and what the user could get to open it. (Would be nice for whoever did the "WINMAIL.DAT" crap...)
These days, it seems that creator codes aren't useful anymore since any number of documents can be created in any number of programs, and binding a document to who created it is less useful these days. Type codes are still useful, though, though the expressiveness of modern extensions makes even type codes obsolete.
Re:Even better. (Score:3, Informative)
The only meta-data attached to a file sent by e-mail is the extension and the mime-type. If your default .doc opener is OO.o, it should work fine.
You'll only see this problem when you get files in storage formats that support file meta-data. Some compression formats support it, and removable storage may or may not.
Re:We Know Best (Score:3, Informative)
File Association Hijacking (Score:5, Informative)
He also explains how to work around the problem
It's not a problem, it's a fix. This is the way it should work.
Suppose I put a Word document on a computer where OO.o is installed instead of Office. The document says "open me in MS Word". The OS says, "Word isn't installed". What happens? What originally should have happened: The OS looks at the document, says "Word document, open this with OO.o", and everything works great. The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.
That's always the way it worked. If you had a Word file (Type=W8BN, Creator=MSWD) on a system without Word (MSWD) installed, the system would identify any other applications capable of opening W8BN files, and open it using that app.
The extra information only came into play when there was more than one application capable of opening W8BN files. It prevented the common Windows practice of "hijacking" another application's file extensions.
Re:quicktime (Score:5, Informative)
According to the Ars write-up, the features are missing because Quicktime was completely rewritten to be a more modern codebase. Among other things, this was required to be able to get it to run on the iPhone. Unfortunately, this also means that some features are still missing. Apple has told developers that they intend on bring Quicktime X back to the level of Pro soon.
Also, some of the awesome features of Quicktime Pro were so embedded in the system that they caused a real problem for movie viewing. Most media formats stream data in a way that quicktime doesn't like - it wasn't to know when the beginning and end are so it can do all of its fancy frame-by-frame selections. So if you read in a divx avi file with an mp3 soundtrack, it had to load the entire file, generate its editing information, and convert it to a .mov in the background to even play it. Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.
Creator codes have been deprecated since 10.4 (Score:2, Informative)
Apparently, everyone has forgotten that UTIs have been in use since Tiger. [arstechnica.com]
By the way, Slashdot, nice job not posting a link to Arstechnica's epic 23-page Snow Leopard review [arstechnica.com] from last week. It's not like they put out the most detailed reviews in the industry or anything.
Re:It actually works just fine (Score:3, Informative)
I think the complaint is that apps in 10.6 are not flagging their own documents to open with themselves.
That is not the complaint in the article. The complaint is that Apple removed the old way applications flagged documents to open in themselves and does not seem to have provided any way for applications to do that using the new method. Rather, applications can tag documents, but the user must still go through and select the files by hand or using a non-obvious script to open in the application after each file is created. It could be that the article writer is mistaken and there is such a method, but no one has yet pointed it out that I've seen and the documentation from Apple is vague and does not seem to provide a method.
Re:We Know Best (Score:3, Informative)
Re:We Know Best (Score:2, Informative)
If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you are now screwed. You can either set .jpgs to open in one, or the other...
Well not exactly. You can still have your default jpeg viewer be Preview, and still have only particular jpegs open in Photoshop. That's easy enough to accomplish. The difference is just that jpegs saved in Photoshop are not automatically associated with Photoshop regardless of the default that the user has set.
And it's not that I fail to recognize how it might be useful to have jpegs created in photoshop always open in Photoshop, automatically. It's just that I don't think it's a very sensible way to handle things. If I really want to use Photoshop most of the time, I can set that as my default jpeg viewer. If I have particular files that I'm opening all the time and want to open them in Photoshop, I can set that manually on a per-file basis. However, when I set a default viewing application for a particular file-type, it's nice for that decision to be honored by the OS.
WTF ? Unix uses file extensiojns ? (Score:1, Informative)
Re:We Know Best (Score:1, Informative)
The Mac OS type system is absurdly complicated.
Determining the application takes into account:
Creator Codes (4 character codes), the file type determined, the file type code, a piece of metadata known as a UTI, the available applications, the UTI's the applications claim to support, the file extensions the application's claim to support, any application explicit bound to the file, The creator codes the applications claim to support, the version numbers of the applications, the classic/OSX status of the apps, of the app, if the app is on a local or network drive, which local drive the app is on, and a few other things.
The result was that unless you bind a file specifically, or explicitly chose a default program for a filetype, it would normally be opened with the prograqm that saved it, but not always.
One can still explicitly bind an application to a specific file, which will override all other considerations. One can still set the default applications for specific types, Which take precedence over other information, except file specific bindings. File types, UTI's, and (I think) file codes are still in use.
So now generally speaking, the preferred app is: the explictly bound app, the explict default app for the file type, or an implicit default app for the file type which is almost impossible to pre-determine, but remains consistent for all files of that type.
To specify a specific app for a specific file, use Finder's Get Info Dialog for that file. That dialog can be opened through the context menu (among other ways).
To set a default app for a file type, use the open with dialog, and check the "Always Open With" box. The open with dialog can be access from the "Other applications" option in the context menu.
Re:Problem? (Score:5, Informative)
So let me get this straight.
Fail. The GP was saying that he'd set all AVI files to open in VLC. In spite of that, some would open in QuickTime anyway because that's what the creator code indicated, which confused the GP greatly because he didn't know that such a mechanism existed.
Re:Creator codes have been deprecated since 10.4 (Score:3, Informative)
But UTI is in no way a replacement for a creator code.
The most useful aspect to me was that one can tell that the particular file has to be opened by different application.
E.g. for most of smallish stuff I'm using QuickTime Player. But most of my movie collection is marked as to be opened by MPlayer. Files types are the same - but different applications are used to open different files.
Or bigger (to organization of my personal information) example are plain text files. On my Mac OS X MacVim is used as default editor. But I also have number of text files which I open and print only from TextEdit.
Creator code was allowing to set non-default application to open the file.
P.S. That was BTW one of the most missed features when I worked under Windows: allow shortcuts to have customized application and customized action for opening the file. After gaining access to Macs I naively thought it was another cool feature. It doesn't look like an ancient artifact to me.
Re:Creator codes have been deprecated since 10.4 (Score:4, Informative)
Oh... I digress. The RTFA explicitly says that Finder's "Get Info" window still allows to change application to be used to open the file. IOW, I'm on safe side as it is how I usually do it anyway.
P.S.
Evidence provided through an anonymous tip suggests that removal of the influence of creator codes in Snow Leopard was deliberately imposed by management on engineering. Since engineering's hands are tied, bug reports to them are likely to be met with the usual "works as intended" brush-off.
If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.
After RTFA it seems to me the issue was greatly exaggerated.