Snow Leopard’s Giant Step Backward
4 September 2009 1:05 pm UTC
Update: please see our post about LaunchCodes
I’m loathe to criticize Apple, I really am. There’s no other company I would allow so much control over my life. I sit here every day happily coding away in Cocoa and, for the most part, loving it.
But I have to say that Apple has made a huge, dumb mistake in dropping creator codes from Snow Leopard.
Years ago when I was a middle manager in an organization, the people in my division had Macs. We were doing very well until a new boss replaced our Macs with PCs. Many frustrations followed, not least being unexpected behavior when double-clicking on a file.
“Windows is not as smart as Mac,” I kept telling my charges. “When you double-click a file, the Mac knows what do because the file has a hidden creator code. Windows has only the extension to go by.”
Now it is 2009 and when it comes to double-clicking a file, OS X is as dumb as Windows.
As I write, I have two Macs before me, one running 10.5 and the other 10.6. On the 10.5 machine I do this:
In BBEdit, make a new file and save it as test.txt.
In BBEdit, make a new file and save it as test.html.
In BBEdit, make a new file and save it as test.css.
In Nisus Writer Pro, make a new file and save it as test.rtf.
In Pixelmator, make a new PNG file and save it as test.png.
When I double-click each of those files:
test.txt opens in BBEdit.
test.html opens in BBEdit.
test.css opens in BBEdit.
test.rtf opens in Nisus Writer Pro.
test.png opens in Pixelmator.
That is exactly the behavior I want.
Now I repeat this exercise on the 10.6 machine. The results:
test.txt opens in TextEdit.
test.html opens in Safari.
test.css opens in DashCode.
test.rtf opens in TextEdit.
test.png opens in Preview.
Snow Leopard takes one of the Mac’s most elegant features—launching the correct application for a file—and desecrates it.
This situation is particularly egregious with respect to PDF files. Let’s say a PDF file contains application-specific data (as the PDF spec allows). When I double-click that file, which application do I want to open it? Let’s take a wild guess: I want to open it in the application it was intended for. I want to open it in the only application that can read its app-specific data. I sure as hell don’t want to open it in a generic PDF reader.
I can hear Preview smirking, “All your PDF are belong to us.”
I never create an html file with the intention to view it right away in a browser. I create it because I am working on a web site and I’m going to deploy the file to a server when I’m finished. The same goes for .css files and images.
If I choose a specific text editor from among the several on my Mac when I create a new .txt file, that’s a pretty good clue that I want to use that same editor to edit that file. Does anybody create a text file in one application with the intention of editing it in another?
Nisus Writer Pro and TextEdit both create .rtf files. I’ve never had a problem with that. If I create a .rtf file in Nisus, then I’m likely do complex things with the file (tables, columns) and I want henceforward to open it in Nisus. If I create a .rtf file in TextEdit, then it’s bound to be a simple file that I can keep editing in TextEdit. I want, forever, to open the Nisus file in Nisus and the TextEdit file in TextEdit. Is this concept somehow challenging to understand?
I would like to know what problem Apple thought they were solving by dropping creator codes from Snow Leopard.
The closest thing to an explanation I’ve been able to find is this statement from an Apple engineer:
“When I save a JPEG file in an image editing app, and later open it, I expect it to open in Preview (or whatever my default image viewer is), not the image editing app.”
Now, that engineer is a man whom I know, like, admire, and respect. I hold him in the highest esteem. But in this case, he is just comically wrong. Does he really think that workaday blokes who create a file always get all their work done in one go, and never have to edit the file again, and go on their way rejoicing and henceforward opening the file in a generic viewer?
Want some salt in that wound? Listen to this:
“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?
When you’ve used a Mac for over twenty years, and it has always done the right thing, and now it often does the wrong thing, the feeling is a lot like betrayal.
It is still true that daily I sit here happily coding in Cocoa. But every day I double-click a file that opens in the wrong app, and then I seethe with the fury of the burning sun. Apple, how couldst thou?
Leave a Comment
4 September 2009 3:14 pm
Ironically, I’ve always felt the opposite—although I admit I used Windows for many years before getting into Macs—that on a Mac, when I had a particular kind of file, say a .html file, I could never be certain before double-clicking it which app would open it: usually Safari, though sometimes inexplicably Firefox, or TextWrangler. Ultimately the insecurity caused by this uncertainty has led to me very rarely opening files with double-clicks on the Mac, instead keeping my most-used applications in the dock, and dragging the file to the application I want to open it with.
Of course, as a programmer I understand how creator codes worked, and why a file might open in one app or another; it just never made sense to me as a user. So to me, the change in Snow Leopard is beneficial.
Obviously I understand how important this functionality is for you with PageHand, and I hope you find a way around it. Does the mimetype-based file typing that was introduced in Tiger or Leopard perhaps offer a solution?
Andrew Durdin
4 September 2009 3:56 pm
I have a solution in place for Pagehand. No feedback yet, so I assume it works. This still bugs me, though, for other apps. For example, I create lots of .txt notes in TextMate, and it bugs me that they open in TextEdit. If I wanted them to open in TextEdit I would have created them in TextEdit.
Ross
4 September 2009 4:52 pm
That would be me. I continually annoyed by the fact that Mac OS X would ignore -my- preference and open documents with whatever application created them. This happens very frequently in a networked environment.
Indeed, the time where I do use Finder’s Inspector to override the application which should open an document is where I want to reset a document “back” to opening in the application I want it to, instead of what the creator code reckons it should.
Mo
7 September 2009 4:03 pm
The new behavior is perfect for me, here is a example:
I put together a graphic with Pixelmator or Drawit and save the master in the app´s format.
If i double click that it opens in the proper app.
If i actually want to use the graphic, i open it and export it as say .png file…
Now that new graphic.png i would never expect to open with Pixelmator or not to mention Photoshop, which is a pain in the butt to load…
The old scheme was always forcing me to right click a file and go to open with in order to get surely the default app. It is more consistent now.
Assuming you have BBEdit and Nisus Writer Pro in your Dock you could drag those file to the Dock icon to open in that app. I can understand your frustration some how but personally i like it better now.
Chriss
Christian Schuster
7 September 2009 4:17 pm
Chris, that’s a good point. I wonder if there is some common ground that would address your and Mo’s concerns while still allowing me to create a .txt file in TextMate and have it open in TextMate instead of TextEdit.
Ross
7 September 2009 6:06 pm
Thanks Ross,
Sure: If you save a Keynote document, you have the option to set a checkbox either to contain the used images or not.
At this point ( save dialog ) or in the applications preferences could be on option for that.
File > New > SaveButton ( “always open with this app” option checked NO )
Application creates new file on disk.
Done.
File > New > SaveButton ( “always open with this app” option checked YES )
Application creates new file on disk.
Application changes “always open this file with” flags to eg. TextMate
Done.
You might submit a feature request for that to the makers ?
PS.
A Email notification for responses would be cool here
Christian Schuster
9 September 2009 1:18 pm
Hi,
Can you tell me what your solution is ? I would guess it involves “pretending” the user has selected a preferred application for this file, but I didn’t find a way to do this in the Launch Services documentation. Or are your directly adding the ‘usro’ resource in the documents (assuming the preferred application is still stored there) ?
Thanks
Patrick Stadelmann
9 September 2009 1:47 pm
Patrick, I just made a special-purpose executable for Pagehand files and allow the user to designate it as the default PDF app. The usro resource, IIRC, is undocumented and uses a path to the application, so it will break if the user moves the app.
Ross
10 September 2009 9:41 am
There are calls in Launch Services to do this, but they are undocumented. However, System Events can be asked to do the job using Apple Events. Here’s how it looks in AppleScript :
Patrick Stadelmann
21 September 2009 10:28 am
I’ve used a Mac for over 20 years, but as a writer/general nerd, not a coder or graphic designer, so my perspective is different.
For me, this change is welcome. I’ve always, always hated how sometimes an image would open in Photoshop, or a text file in BBEdit. When I want a heavy duty app, I launch it an open files from it or drag a file onto it.
It’s is much better for the average user for files of a particular kind to always open with the same application, no matter what application created them. Why do you think Apple made the change?
Going forward, there can be an option in apps to automatically bind files if you like. But the old way was clearly busted as way too many apps simply made themselves the owner of every file they saved (which it was never necessary to do btw).
The biggest problem was how this metadata travelled from machine to machine, as if it matters to me that a particular file was created in such and such program on someone else’s machine.
jhn
21 September 2009 10:37 am
Why the hell have they done this? Utterly bizarre thing to do. Idiotic.
WOPR
21 September 2009 10:41 am
In the Windows universe.
Except that, they don’t do it. They just live with the “One App Owns Them All” feature.
jabsonik
21 September 2009 10:56 am
I can see how this change could seriously disrupt one’s workflow precisely for the reasons stated above.
That said Creator Codes have been a pain in my rear for years. I loathed that my images exported from Photoshop wouldn’t open up in Preview by default. I could never be sure if an image would open in Photoshop or Preview. Once I export a file I’m done with the app that created it and it should behave like any other file of its type.
Good riddance to Creator Codes.
Dan N.
21 September 2009 10:59 am
I think this is one of those situations where Apple was never going to make everybody happy. I’ve been using Macs nearly as long as they’ve existed, and Apple products longer, and in many ways, sure, going from creator codes to file extensions was a step backwards.
However, the scenario put forth by the Apple Engineer that you dismiss as “comically wrong”, is exactly how I feel. Just because I used Photoshop to edit a file at some point, or even to create it, doesn’t necessarily mean I want that behemoth of an application to launch every time I double-click that particular file. As long as I have a way to specify that an individual file should open with a different program, I personally prefer to have documents open with the default application for its extension if I haven’t specifically said otherwise.
Yes, it’s a change from the days of classic Mac OS, but it’s not as abrupt of a change as you make out. An awful lot of programs simply don’t use creator codes any more – in Cocoa, they’ve always felt like a bit of legacy metadata that shouldn’t be there anymore. Sure Photoshop and Nissus Writer (which are both old Toolbox apps using Carbon) do, but many apps created more recently (say, in the last decade) do not.
It’s about time we got rid of that cruft and had a system-wide standard behavior. Yes, some people are going to dislike the new behavior, but you’ll adjust. Progress is not betrayal, but sometimes progress comes with some pain.
Jeff LaMarche
21 September 2009 11:05 am
File it as a Radar bug. Hopefully if enough people complain they’ll add the functionality back in in a 10.6.x update. Here’s hoping!
Matt Bland
21 September 2009 11:14 am
As a long time mac user, this is depressing. I don’t own Snow Leopard yet, but I probably will at some point in the near future. A definite bummer.
Nice write-up describing the behavior (and why such a little omission can mean a definite, and annoying, change to one’s workflow.)
Andrew Embler
21 September 2009 11:15 am
The JPEG example is particularly peculiar as JPEG simply is not a file format you would _work_ with but just one you _export_ to. As such the described behaviour may be adequate for that case (and one could argue that applications exporting JPEG files should not set a Creator code because of this). Hence your friend may be correct. But that is only true because of the specific and very particular nature of this file format.
ssp
21 September 2009 11:19 am
I’m with you on the betrayal thing. You’ll have my name in any petition. Why Apple? Why?
Daniel
21 September 2009 11:20 am
I absolutely and fundamentally disagree.
Any user ALMOST NEVER wants a file to open in anything other than the default they choose for a file type. In those very rare exceptions, you can just drop the file into the app you want.
I don’t want applications deciding for me that they know better than I do, which is exactly what a creator code was.
This was a very sensible move on Apple’s part, and completely in line with what all users want and expect.
Martin Coxall
21 September 2009 11:21 am
Maybe if enough people complain about it, they might put support for creator codes back in:
http://www.apple.com/feedback/macosx.html
George
21 September 2009 11:51 am
I hadn’t noticed this, yet. Mostly because I tend to drag-and-drop files onto Dock icons to open them. But Snow Leopard breaks this behavior, too. You can see what I mean on my site.
I’m beginning to believe that Snow Leopard is a boondoggle.
Michael Critz
21 September 2009 12:28 pm
That sucks I’m sorry. The problem that the engineer mentioned was mine. I would open up a jpeg created in Photoshop just cause I wanted to see it and instead of Preview opening up, Photoshop would. Kinda drove me a little nuts at first.
Granted, this is/was an easy fix for me, I could have just had preview open all jpeg files and whenever I wanted to open up a file in Photoshop, Control-click and choose Open with Photoshop. Not a big deal, but I’m pretty comfortable with a computer.
I would imagine users not so comfortable with their computers something like this might confuse them a bit (although, if that’s the case, I don’t see them doing a whole lot of Photoshopping or web developing).
Since he used an image example, I wonder if this was a common complaint from users? Why not default jpegs and other image files to open up in Preview and leave everything else the same, if possible?
portorikan
21 September 2009 12:32 pm
I think Apple has taken a decision for which “most people” (that is, people from the Windows world) would expect file associations to work. And, while I don’t like some of the changes in Snow Leopard (for one, Exposé’s “grid” is counterproductive for me) I think the abolition of type/creator codes is an improvement.
Type/creator codes are, for most part, completely hidden to the end user. There is no way for end users to manipulate them without downloading a special utility. On the other hand, the new behaviour is consistent – without losing any functionality for advanced users.
Under the Leopard way of doing things, an PSD image, for example, would open with Photoshop (which takes forever to load) and under Snow Leopard, it would load with Preview instead. Similarly for HTML files, it is annoying when it loads up a beefy HTML editor, when I merely wanted to look at the HTML file in Safari or Firefox.
Advanced users lose no functionality – they can use “open with” to open with a different program, drag the file to the relevant icon on the Dock, or, as the Apple engineer described, permanently change it using the File Inspector.
Si
21 September 2009 12:48 pm
Would it be possible for new versions of apps to be updated to set the file to open with that app when creating the file? Essentially automatically doing the work around.
Matt
21 September 2009 1:08 pm
In what universe does a devout BBEdit user have his default for CSS files set to Dascode? Why is your defualt set to any of these apps when you clearly have a strong preference for all of them?
If you opened files 50/50 in your predered app vs a specialized app I could see your point but I’m guessing it’s 20/80 for the default app (if not 10/90), in which case what’s wrong with drag and drop?
Oliver
21 September 2009 1:09 pm
This is awful. This is in fact one of the standout features that I use to tell people about how the Mac does things better than Windows. The occasional surprise of a file opening in the wrong app was a reasonable price to pay for the beauty of having the computer do the right thing almost all of the time. If this is gone in Snow Leopard, then I’m a little miffed. Here’s hoping this gets changed, although I doubt it will.
mauvedeity
21 September 2009 1:36 pm
This sounds like an opportunity in disguise. Either for DefaultApp or some new utility to override this and allow customizable logic. That is, ‘TEXT’ and ‘PDF ‘ type codes bind to creator, others go to default apps regardless of creator codes, etc…
Blain Hamon
21 September 2009 1:38 pm
I absolutely disagree – the current situation, as it’s been on macs since time immemorial, has been that you simply don’t know which app is going to open a document. So out of fear – fear of launching some giant space whale of a program like photoshop, I’ve resorted to almost never actually double-clicking on documents of a ‘dangerous’ type (e.g. anything that might open in a big, clunky app). I almost always drag to the dock or open with out of avoidance of the old, broken feature.
I also can’t describe how much frustration I’ve had with the “always open type X in app” setting that until now simply never worked, because it was overridden by creator codes.
Apple just fixed one of the most unintuitive bits of brokenness in their OS. Please don’t canonize the bug, or we’re just as bad as the windows community in clinging to things that suck simply because we’re used to them. Seriously – the current way only makes sense to some people because they’re used to it. And even to a lot of dyed in the wool professionals like me that have been using their mac since the SE days, it actually doesn’t make sense and is broken. Until snow leopard, the ability to double-click on an app was broken by how convoluted the rules were. Please let them fix this long-running mess.
Richard
21 September 2009 1:38 pm
Amen, brother! We need a petition. This is an outrage. (Also a NWP user.)
Ast A. Moore
21 September 2009 1:42 pm
Just adding another voice to the crowd of folks who welcome this change. I always want html files to open in BBEdit. However, Dreamweaver is on my machine, and if someone else who prefers that editor sends me a doc, i have to manually change it every time or suffer the long, mistaken load of Dreamweaver when I absent-mindedly double-click. Makes co-editing a nightmare.
Brian
21 September 2009 1:50 pm
I understand your position, as it’s clearly a feature you take advantage of and rely on. Myself, I spent most of the time cursing the damn ‘feature’. Usually I *do* want to open files I created in the fast generic viewer that’s already running.
I like Christian Schuster’s suggestion of a Save option checkbox. Nice and clean. Personally, all my gripes would have been solved by heavyweight, document-creation apps not associating themselves with *exported* files.
Dave Richards
21 September 2009 1:55 pm
Is it just me, or does it seem that Apple is totally on crack these days? It has totally busted another Microsoft move with this and a few other SnoLeo miss steps. I am absolutely missing AppleTalk for accessing a perfectly good legacy printer! I know, it had to go eventually, but man this HP LJ4MP just won’t die!
RASTERMAN
21 September 2009 2:50 pm
I am not a programer or even a power user but like you, some pdf files need to be opened in Acrobat and others in Preview, some jpeg files in Photoshop and others in Vectorworks. If I had known of this fatal flaw, I would never have upgraded to Snow Leopard. Now I am screwed. They need to fix this NOW!
Mark
21 September 2009 3:03 pm
I have to say that I find this new behavior mostly beneficial. In the past I’ve always had to right click on a file to find out where it was going to open instead of just double clicking on it. This is because in general, editing apps take far longer to launch than the default viewer apps. There is nothing more annoying than double clicking on a file, expecting it to open textedit, quicktime player or preview and instead find yourself waiting for a heavyweight editing program to launch and load the file all so you can just quit the app immediately anyway.
Now I can just right click when I want to edit something instead of for every file that I want to open. I don’t see that right clicking and choosing an application for the times when you want to edit is such a big deal. Even if you end up in the wrong app the first time, it almost always going to be the lightweight and quick to open viewer application.
James
21 September 2009 3:11 pm
For the record, I prefer the old way, specifically because of multiple-application file formats like RTF or even, to some extent, PSD, which is used by a few other image applications as a standard save format.
Still, it’s weird reading all the people defending the new way because they hated clicking a JPG and having it launch Photoshop. For me, JPG, PNG, and GIF have always been finished export formats, not work-in-progress save formats, and therefore the first thing I would do on any new system was to use Get Info to set those filetypes to always upon in Preview. Problem solved. I still had automatic creator binding for other file formats but NEVER had image files accidentally launch Photoshop …
Cooner
21 September 2009 3:36 pm
I’ve been so happy that Snow Leopard is finally doing the right thing! Which directly contradicts your premise.
I can kind of see the theoretical benefit of creator codes, but it’s been far outweighed in my experience by the fear-factor, the way that any random JPEG on my hard drive could be a lurking Photoshop-launching monster.
Also, I do create text files with various different programs _all the time_ that I want to open in my default editor, TextMate. I’ll save text or code files from Coda, from Safari or Firefox, from Stickies (very frequent)… but almost always I want to open/edit them in TextMate; that’s where I live.
Coda’s a fine example here — when I’m going to Work On A Site, I fire up Coda and open the site; it’s project-oriented. When I need to make a quick change, I navigate to the folder and open the file in TextMate. This was always screwing up with Leopard, because I’d double-click a file in Finder and it would open in Coda.
The creator code mess has always seemed like a messy remnant of the System 6 days, and I’m delighted to see it go away and quit bothering me.
Dan Hallock
21 September 2009 3:36 pm
1. Put icons for your apps on your dock.
2. Drag the file to the non-default application.
Frankly, creator codes have always been annoying for me. When I want to double-click on a JPEG or PDF, I always want it to open in Preview. When I want to edit them, I drag them to the appropriate app for doing so.
Likewise for DOC files, RTFs, HTML, etc.
I used to find it a colossal nuisance to open a picture ONE TIME in Photoshop to make an adjustment, and then have Photoshop usurp Preview as the default program for that one file. Easily fixed, i know, but still annoying.
So… learn to drag to dock icons to get by.
Vandil
21 September 2009 3:39 pm
Cooner — the point is that creator codes didn’t respect your defaults. In Leopard, you _can_ set JPEG files to always open in Preview, and a Photoshop-sourced file with a creator code will still override your default and open in Photoshop instead.
Dan Hallock
21 September 2009 4:20 pm
Everyone who agrees should file a bug with Apple. The only way to get things fixed.
Doug
* goes to file bug *
Douglas
21 September 2009 4:32 pm
I imagine some yahoo at Apple is thinking yeah, but this is all a bit of a kludge isn’t it, and it’s not how the web works. Well Apple should have extended the system – because it is useful. Here’s how you could extend it:
Firstly, if an application creates a file that file should by default open in that application – this makes perfect sense, however, it would be nice to be able to use get info to override this default. It would also be damn useful to be able to define “operations” that would be accessible from a “right click” that would provide named overrides (so you could imagine a PDF might have “preview” that always opens the PDF in preview, or an HTML file might have ‘check’ that would open it in Safari, and of course something I name that passes the file to an AppleScript for it to work on the creator code should be available inside AppleScript.
The UI isn’t even a complex problem! (maybe the AppleScripts should live in a particular location, to keep things simple) This could be done with the MetaData that the Mac uses.
Jeremy Chappell
21 September 2009 4:45 pm
This is a particularly maddening change for those of us who use Fireworks, which uses an extended version of the PNG file format for multi-page, layered master files. Preview and all other image viewers just render the first page as a static bitmap, but I definitely don’t want Fireworks set as the default PNG handler since it takes a while to load and (still) has stability problems.
Daniel J. Wilson
21 September 2009 5:04 pm
Great post, this is the dumbest mistake Apple have made since, oh say 10.5 with the braindead stacks feature which removed the ability to simply open a normal Finder window for a docked folder by single-clicking on it. Even today they keep stacks as the default behaviour and force you to muck about with setting individual options for each docked folder you create to enable the old vertical scrolling list behaviour, and Apple force you to now right-click and select the open menu item on docked folder icons to do what used to be a quick single-click operation.
BTW, “enhancing” stacks so it simply more closely emulates opening a folder in a Finder window is the second dumbest 10.6 mistake/waste of time after ignoring creator codes.
Expecting normal users to comprehend the difference between the dock and stacks (where single-clicking opens things) and the Finder (where double-clicking is required) is a problem in general, the Mac has become much more confusing and inconsistent for users. Not an improvement.
David S.
21 September 2009 5:18 pm
This is the only Snow Leopard feature that has made me put off upgrading to it. I don’t have time to deal with the fallout from this across thousands of gigabytes of files.
> When I save a JPEG file in an image editing app,
> and later open it, I expect it to open in Preview
That is not what a Photoshop user (for example) would expect. If they save a JPEG (typically a big camera JPEG) from Photoshop they want it to open back up in Photoshop, they’re using that as their master document. Many photographers don’t use PSD because they don’t have the disk space. It’s only if you “export” a JPEG (typically scaled down and Web optimized) that it should open in the default app, and the mechanism for that is when applications export documents they should leave the creator code blank.
This is a drag because we are having the “developer way” pushed upon us. Developers love to have a personal list of application bindings (“my preferred text editor, my preferred image viewer”) like a butterfly collector, but I find that whole thing to be a drag. The way I specify my preference for a particular app is by using the app to make documents. You can look at a disk of mine and see 47% of the files have the BBEdit creator code and 27% have the Photoshop creator code if you want to know what apps I prefer. You don’t have to ask me to fill out a survey so that every time I open a file you can make an educated guess about what application to choose out of the universe of them to open a file I just made 2 minutes ago in Photoshop.
This is also a change that is too big for users to have to notice it. In other words, if you’re going to drop creator codes, it should be in a way that nobody notices. It’s hard for anybody to complain about losing AppleTalk when we’ve had Bonjour for some years now which is essentially AppleTalk for the Internet.
Hamranhansenhansen
21 September 2009 6:00 pm
This is a very strange situation indeed. If Snow Leopard isn’t honouring creator codes, yet you can still get-info on a file and set it to open in a particular application, then how is this information stored?
As this information must be stored as metadata somewhere in the filesystem, then all the application writers need to do is set the app to save this metadata to the file when they save the file.
Then, the file will open with the app, as expected, and it’s not using old-and-busted creator codes, it’s using the new-hotness metadata.
Kai Howells
21 September 2009 6:34 pm
Kai, I wish that were possible. The API for doing that is undocumented, and AFAICT the metadata stores the path to the app, not its identifier, so if the user moves the app the association is lost.
Everyone, what about Christian’s idea that the Save dialog could have a check box “Always open this file with [app name]“? Wouldn’t that be more useful than the “Hide extension” checkbox? If the extension determines which app opens a file, why would you want to hide it anyway? (Especially those files whose icon gets changed to a preview image.)
Ross
21 September 2009 10:10 pm
The old behaviour only really works in specific use cases. It doesn’t work for files like jpg, pdf… etc. You don’t “create” a jpg file, you copy it off your camera or export it from photoshop. Same for pdf. When you create a pdf and intend to edit, you probably used adobe illustrator and will have a *.ai file. Similarly if I browse my iTunes or iPhoto library in Finder, i don’t want them to open in iTunes/iPhoto, I expect QuickTime/Preview.
The other of the problem with creator codes is they only work sporadically. In the old days, chances were a file created on a mac/pc couldn’t even be opened on the other platform. But that’s not the case today. We live in a cross platform world and macs aren’t “smarter” when they do weird stuff because a file has no type/creator. If you can’t do something properly, you shouldn’t do it at all. Maybe snow leopard’s behaviour isn’t always what I want, but as often as not it *is* what i want, and it will always work exactly the same way. That’s worth something.
It’s just like the old “clippy” in microsoft office. It’s a great idea, but because it doesn’t work properly it does more harm than good.
I’ve been using macs daily since system 7, and am more than glad to see creator codes go away.
Abhi Beckert
21 September 2009 10:54 pm
If they really needed to get rid of creator codes for some reason, it would probably be a simple thing for them to update the Cocoa APIs to create said document bindings for you based on the creator code the app tried to save the file with. Too bad they didn’t think of that ahead of time.
Dave
22 September 2009 3:09 am
Let me save Apple the bother:
“closed – works as intended”
And not only does it work as intended, it works AS IT SHOULD, as every user expects. Thanks, Apple. This was the right decision.
Martin Coxall
22 September 2009 8:00 am
If the ‘Always Open with filetype with x” over-rides the creator code then we can have the best of all worlds.
If we can set a filetype to always open with a particular app, or to honour to creator code if present, then we all win.
Michael Ward
22 September 2009 12:07 pm
Is this a workflow thing? You use JPEGs as an example, but some would say that you should never save an image as a JPEG, but rather — if you use Photoshop, say — as a PSD with an export to JPEG. PSD is lossless, supports editable text, etc, etc, etc, and repeatedly editing a JPEG is a bad practice if quality matters.
Similarly, I work in video using Final Cut Pro, and obviously my projects are saved as FCP projects, with an export of a Quicktime file at the end. How many times have I clicked on an FCP-created Quicktime only to have it open in the world’s slowest QT previewer (FCP), which also happens to have zero tools for manipulating QT files. Interestingly, Quicktime Player is a fast previewer and also happens to have (in the Pro version) many tools for manipulating QT files (tracks, formats, presentations, etc).
So the difference would be in workflows. Workflow Type 1 includes those who work on sets of identically-formatted files using a set of different tools depending on the task for each file: Photoshop for this image, Aperture for that image, Pixelmator for the other image. This may also be especially applicable to programmer (including HTML, CSS, etc) jobs.
Workflow Type 2 includes those who work on projects as in Final Cut Pro or Logic or Pages, where you have a project that includes much more information than makes it into a final product and your final product is essentially rendered or mixed down to a final product. (As I mentioned above, some might use Photoshop in this way, with a PSD project file and rendered output in the form of JPEG, TIFF, etc, or perhaps sliced images.)
Make sense?
Wayne
22 September 2009 1:50 pm
jhn: “It’s is much better for the average user for files of a particular kind to always open with the same application, no matter what application created them. Why do you think Apple made the change?”
The great thing about Macs, from long ago, has been that they do something that works very well for both beginners and experts. It wasn’t at all unusual to walk into an Ivy League CS department in 1995 and see wall-to-wall PowerMacs, same as the art department across the quad.
The sad thing is not that they changed this specific behavior, but that they seem to be punting on the very idea that there’s a good design that works well for novices and experts. Either that, or that copying the Windows way (to be more familiar to more people) is more valuable than keeping a very useful feature that many people love, and which was not originally added without good cause.
Ken
22 September 2009 6:05 pm
Looks like Apple has chosen to have a better system, based on UTI.
http://www.appleinsider.com/articles/09/09/22/inside_snow_leopards_uti_apple_fixes_the_creator_code.html
MacademiaNut
23 September 2009 1:40 am
For UTIs to provide this functionality, a way to assign them to individual files is needed. AFAIK, this is not possible, even for the application creating the file. It is the system that assign UTIs, and so it appears impossible to have file1.txt and file2.txt show a different list of UTIs…
Patrick Stadelmann
23 September 2009 2:40 am
This is exactly the behavior i DON’T want, that is imposed on me by some apps, in an INVISIBLE way.
The way OS X 10.5 handles file-application association has always seemed strange and unpredictable to me. Most of the time i can predict what will happen when i double-click a file, but there are just enough exceptions and surprises to make the whole thing uncomfortable. With time i realized that some applications would silently attach themselves to some files they create or edit. Photoshop is one such offender, as it would attach itself even to files created using the Export for Web feature; a behaviour you can only learn through pain-in-the-arse trial and error, because:
1. optimized images are not working drafts that you would want to edit in Photoshop again (you would go to the original file);
2. the image’s icon doesn’t show that it’s associated with Photoshop.
If they solved problem #2, that would make the interface more predictable, but for me it would still suck as i like to get a unified behavior for all files of a given file type.
On the whole, i really don’t like the way file-application association is handled in OS X. There is a lot of hidden complexity here. Most tellingly, the Finder allows you to micromanage associations on a per-file basis. That’s the default behavior in the File information windows; you have to use an option if you want to manage a file type rather than the one selected file. And even when you use the right options to stay clear of file association micromanagement, there are a few hidden things lurking about like that creator code thing. I say good riddance, that’s one less gotcha.
My favorite file association mechanism so far is what Nautilus does on Linux (Gnome). Extensions take precedence but file types are recognized even if the file has no extension. In the file property window, there is a tab with the title “open with”, where you can manage the applications for a specific file type: which ones will be listed when right-clicking the file, and which one should be the default. The OS and applications manage that list, but you can customize it. Furthermore, applications are more conservative when declaring the file types they can handle. On OS X, if i right-click a JPEG and try to see what applications i can open it with, there’s a 2 second lag before a list with 20 applications or so show up; that’s because OS X applications declare a full list of all file types they accept (so that you can drag a file to the application’s icon in the Dock to open that file), but has no concept of “this application is a sensible choice for the following short list of file types”.
Well, at least they got rid of one annoyance in Snow Leopard. That’s a start.
Florent V.
23 September 2009 10:24 am
You are absolutely right. I’ve always tinkered with the file types and creator codes, and wondered why Apple almost pretended they didn’t exist. Works in progress need to retain the creator codes for the most obvious of reasons: we ain’t done with ‘em yet! When we’re done – and we may never be done if they are html files used as a templates or something like that – it’s simple enough to get them changed. We should choose when; not Apple.
So now what… we have to use a script!?
Henry Chance
3 October 2009 9:17 am
As a blogger, I rely heavily on the simplicity of TextEdit. In particular, hitting line break to hotlink (“Smart Link”?) Web addresses.
In SL, TextEdit won’t do that so simply anymore. One must use “Substitutions”!
I can see hours wastedon substitutions! Arrggh!
If anyone has a workaround, please let me know: unblocktheplanetATgmailDOTcom. Thanks…
CJ Hinke
4 October 2009 6:59 am
For those for whom the new way seems to eliminate confusion, the simple common ground solution would be to make type/creator codes transparent, and to allow the user to manipulate them, at least for file types and applications that exist on the system. In addition, it should be deemed a necessity to be able to delete type and creator codes as well, and applications that have no type and/or creator code would then open in whatever the default application is for its file extension. Better still would be a System Preference that would allow the user to designate whether the Finder would prefer type/creator codes, file extensions, or Universal Type Identifiers. This would allow those who understand and want to use the codes the flexibility they desire, while allowing those who prefer to operate in a file-extension-only world their druthers.
Eric
8 October 2009 4:21 pm
It is a pain. I used to edit files opening them directly in Photoshop while working in InDesign by option clicking. Now I have to open up the window and open file or go to photoshop and open. Extra steps make it less productive.
Buck
9 October 2009 9:04 pm
As you know, you can manually reassign the opening application using the Get Info window in the Finder. But if you have lots of files and want to automate this process, it can be tedious. To solve that, I’ve just released SLopen, which is a drag-and-drop app that reassigns the opening app to a document’s creating app. You can get SLopen at chuchusoft.com. Hopefully this will make the transition to SL a little less painful. Cheers.
Vincent Tan
12 October 2009 3:58 am
I couldn’t agree more with you. This should be, at least, configurable through the Finder prefs, or the System prefs, but it’s really annoying. Maybe there’s a hidden defaults key/value one can change through the command line?
Adrian
27 October 2009 3:28 pm
I’ve never think of this as a problem before upgrading to SL, but yesterday when I finally upgraded to SL, I feel other people’s pain in this regards.
I often create forms in Acrobat. Before all I have to do is to Get Info on the PDF I created and choose “Open with” to Acrobat and I’m good to go, and the setting remains even after I edited and re-saved the file. I still like all the other PDF files to open in Preview because of the near-instant loading time.
Now in SL, if I do the same thing, those specific files I chose to open in Acrobat still open in Acrobat, while others open in Preview… UNTIL I opened and edited the file, and do a “File > Save”. Now those PDFs will re-associate themselves back to Preview.
I’m not a computer expert so Apple shouldn’t make me (and among many other users like myself) deal with workarounds or setting scripts to deal with this problem. This has to be fixed.
BCC
15 November 2009 6:46 am
Hear! Hear! I agree
Norman Preston
26 November 2009 6:56 pm
For me, it looks that the creator code (of the resource fork) has been moved into the metadata of the file.
The problem is that TextEdit does still write to the resource fork, and leaves the metadata unchanged.
I agree Ross, this is a step backward, but it is to the applications to make the step, not to the OS.
When you manually change the “Open with” property, use `mdls` from the terminal shell to see the change.
So I ask myself: why does TextEdit not change this metadata property?
I may be ill-documented and badly announced.
That, in turn, would be a shame for Apple, indeed.
Could someone please comment?
cognonaut
25 December 2009 1:08 pm
Update: please see our post about LaunchCodes
Ross
11 January 2010 6:05 pm
Although I’ve had it for some time, I installed Snow Leopard only three days ago. I had a hunch that Leopard did everything I wanted, but I nonetheless followed Apple’s advice as I always have done. I always go for their upgrades. This time I’m really sorry. SnLeopard is painfully slow. Photoshop takes forever to open and close. ANd now there comes the crowning outrage. My Photoshop JPG files are no longer saved as such. This means wasting a lot of time. How can they be so stupid as to do away with creator codes?!!?
I work with different programes, image and text, and I’n damned if I want the versatility that I so admired in Apple taken away. Apple is hijacking other people’s brands in much the same way as Supermarkets do, and rebranding them as their own.
A petition might be a good idea……
Nick Bonoff
11 January 2010 6:20 pm
Nick, I feel your pain. I think the handwriting is on the wall as far as the future is concerned; I don’t expect Apple to cave in, no matter how much we complain. I really think the best solution right now is LaunchCodes.
Ross
20 January 2010 12:44 pm
I am also annoyed. I use TextMate for all my text editing, and I do a lot of it. I use TextMate more than all Microsoft apps put together. I’ll use TextMate to create bits of router config and save it. When I double click on the file, it opens in Text Edit.
I’m nearly ready to delete Text Edit.
Peter
21 January 2010 4:52 pm
Peter, I think LaunchCodes will work great for you. I use TextMate every day, and I no longer have the problem of files opening in TextEdit.
Ross