|
|
Snow Leopard kills Document Creator Codes
|
|
|
|
Mac Elite
Join Date: Nov 2005
Location: Seattle, WA, USA
Status:
Offline
|
|
As explained in this article, Document Creator Codes are a small piece of metadata that are attached to a file when it is created. This metadata is associated with the creating application; for example, Paintbrush uses the code 'Pbsh'. The OS then uses this information to make sure that the originating application is launched when you double-click the document in the Finder.
However, as of Snow Leopard, these codes are no longer respected. All files will automatically launch the system's default handler for its filetype, unless you specifically change the file's default in the Finder's Get Info window.
To me, this is very unfortunate. I do a lot of image editing in my spare time, and I enjoyed having the originating application "claim" its documents. The worst part is that according to the article, this was a management-driven decision, and not an engineering-driven one. In other words, there's no technical reason for this change.
What are your thoughts on this change? Don't tell me I'm the only one that disagrees with the decision.
|
Any ramblings are entirely my own, and do not represent those of my employers, coworkers, friends, or species
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status:
Offline
|
|
Does that mean you could still change the handler for each file, but you would have to manually re-assign a non-default handler ?
Yeah, sounds like a stupid move on Apple's part.
-t
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Jan 2002
Location: Durham, NC
Status:
Offline
|
|
So when you manually assign a different "open with" app on a per-file basis, is it still using the Creator Code metadata? Or is it using some new technique?
More importantly, is there a supported way for developers to let their apps set this whenever they create and/or save a file, so you won't have to do it by hand on a per-file basis?
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
That is an annoying change. I'm also curious about how changing the Open With setting works now.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status:
Offline
|
|
To counter the argument, if I have a default app set for a file type, it tends to mean that I want my files to open in that app even if they were created in something else. Having another app override my default without me expressly changing it for that app is also very annoying.
However, I haven't installed Snow Leopard yet, so maybe it is worse to have it this way around and I just haven't experienced how bad it is
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Most of the time, if I create a TIFF in Photoshop and double-click it two seconds later, I intend for it to open in Photoshop and not Preview. I think this is most people's expectation. The idea that a file I made in Photoshop — that has never been touched by Preview — would open is Preview is kind of weird. Obviously files saved by Safari (for example) shouldn't behave this way, but expecting people to make the leap that "This file belongs to another program than the one I used to make it just because of its file extension" seems rather unintuitive IMO.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Originally Posted by slugslugslug
So when you manually assign a different "open with" app on a per-file basis, is it still using the Creator Code metadata? Or is it using some new technique?
It puts a 'usro' file in the resource fork with a path to the TextEdit application, but I wouldn't exactly call that a "new" technique since it's been there since at least 10.1.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status:
Offline
|
|
Originally Posted by Chuckit
Most of the time, if I create a TIFF in Photoshop and double-click it two seconds later, I intend for it to open in Photoshop and not Preview. I think this is most people's expectation.
Conversely, if I created a TIFF in Photoshop then double-clicked it a week later, my expectation would be for it to open in Preview rather than Photoshop because Preview is my default for viewing images rather than editing them. In other words, I think this is an impossible situation to solve as expectations will vary depending on context. However, as people are already used to it happening the old way, for it to suddenly change will naturally be jarring and is no doubt one of those WTF were they thinking situations. It would probably have been better for Apple to have left it as is.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
They did - for 7 years. The 'usro' resource has been the replacement for the creator code for a long time. Since the usro resource is user-configurable and the creator code isn't, I'm not one bit surprised that they eventually ended up yanking the latter.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Originally Posted by CharlesS
They did - for 7 years. The 'usro' resource has been the replacement for the creator code for a long time. Since the usro resource is user-configurable and the creator code isn't, I'm not one bit surprised that they eventually ended up yanking the latter.
Applications don't set the USRO resource and AFAIK it's undocumented and unsupported to do so, so now we are left with applications being forced to offer a worse user experience wherein the user has to manually set the owner on each and every file even though of course I want my Photoshop files to open in Photoshop. What a pain.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
Applications cannot write usro-resources to own their own files by default. There is no API for it and the format is undocumented.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status:
Offline
|
|
Originally Posted by Chuckit
Applications don't set the USRO resource and AFAIK it's undocumented and unsupported to do so, so now we are left with applications being forced to offer a worse user experience wherein the user has to manually set the owner on each and every file even though of course I want my Photoshop files to open in Photoshop. What a pain.
Wow that's breaking a 1984 UI convention. I'm surprised this is the first we've heard about this.
|
"The natural progress of things is for liberty to yield and government to gain ground." TJ
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
^ And what convention would that be?
I think the reasoning behind that is that it's supposed to be a user preference. Applications aren't meant to be changing that setting behind the user's back - it's supposed to be done only by the user.
If it were really that big a deal, though, you could set it easily enough programmatically. All the usro resource is, is a 32-bit length of the path, the path itself as a UTF-8 string, and a zero byte.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Originally Posted by CharlesS
^ And what convention would that be?
I assume: That documents belong to applications, rather than having the system launch a document in some arbitrary application merely because it shares a file extension with another file you wanted to launch in the other application.
Originally Posted by CharlesS
I think the reasoning behind that is that it's supposed to be a user preference. Applications aren't meant to be changing that setting behind the user's back - it's supposed to be done only by the user.
Is that why creator codes were introduced and respected (and nobody ever complained about them) from 1984 until late 2009? The old behavior of a document creator having the option to own its files and the user being able to override that seems much more reasonable than all files with a given file extension always opening in one program regardless of how they were created unless the user goes through them one by one and changes that.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Jan 2001
Location: Helsinki, Finland
Status:
Offline
|
|
This particular SL 'improvement' is immensely annoying.
I'll just need to unlearn a 20- year habit of double-clicking files to open them and start dragging them into QuickSilver/Dock instead. Oh well.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Originally Posted by Chuckit
I assume: That documents belong to applications, rather than having the system launch a document in some arbitrary application merely because it shares a file extension with another file you wanted to launch in the other application.
Rather, that documents belong to the application you set them to belong to, rather than belonging to some application just because it decided to take over that file.
As an example, I've got Word 2004 on my system for those cases where iWork isn't compatible enough with some file that someone sent, but for the vast majority of Word docs I get I'd prefer to open in Pages. However, save a file in Word for some reason and it sets the creator code to make them open in Word forever. This is annoying.
Is that why creator codes were introduced and respected (and nobody ever complained about them) from 1984 until late 2009? The old behavior of a document creator having the option to own its files and the user being able to override that seems much more reasonable than all files with a given file extension always opening in one program regardless of how they were created unless the user goes through them one by one and changes that.
Dude, you're extremely late to complain about this one. Creator codes have been redundant and obsolete ever since OS X came out. Most Cocoa applications don't even bother setting the creator code - the only apps that actually do are older applications like Word and Photoshop that have been ported from OS 9, and you can expect those to stop doing it too as they get rewritten in Cocoa for 64-bit, since Cocoa makes you go out of your way to set the creator code, and there hasn't been any point in bothering with those things for years. So in a short time, you're not even going to have any apps that set the creator code on files at all. So why does it matter if the OS supports them?
Look, if you want to replicate the old "creator code" functionality, send Apple feedback to put an equivalent in Cocoa that would put a resource in the file's resource fork similar to the 'usro' resource, or even better, an extended attribute that will give a record of what application created it. But make it an optional setting somewhere, so we don't all get stuck with this behavior, and make it based on the bundle ID, a modern piece of metadata that applications actually use. Don't beat the dead horse of the creator code.
(
Last edited by CharlesS; Sep 8, 2009 at 07:43 PM.
)
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status:
Offline
|
|
There should definitely be a replacement for creator codes so that the user could optionally set an application to own the files it creates. What we have in OS X is an all or nothing solution. I've always hated the fact that dumb file extensions replaced types and creators.
|
"The natural progress of things is for liberty to yield and government to gain ground." TJ
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Sep 2006
Location: Back in the Good Ole US of A
Status:
Offline
|
|
I've always been in the habit of right-clicking on files and selecting the application to open with. That way it's never a mystery as to what application will open the file.
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Nov 2006
Location: here
Status:
Offline
|
|
Sometimes a glitch opens an image in preview (I'm currently still on Tiger).
I usually open all RAW images in Capture One, all TIFFs in Photoshop. But I don't work with InDesign or a page layout program, that also uses TIFFs.
That could really get difficult.
I always hate it when management overrides expert knowledge. It's like the marketing people ruling Hollywood and deciding on what gets greenlighted. The junky result you can see in the theaters.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status:
Offline
|
|
Yay! It's so annoying having every Photoshop created file default to launching Photoshop to view it unless you change the default app to Preview for every one of them.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Yeah, now every Photoshop-created file will default to launching some completely different program unless you change the default app to Photoshop for every one of them.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Nov 2005
Location: Seattle, WA, USA
Status:
Offline
|
|
Question time, since I really don't know: how often do people create files in Photoshop that are not .PSD files, save them, and then re-open them for further editing in PS? I realized the other day that 95% of the time, I don't export to a non-PSD unless I'm done editing. And if I do want to make more changes, I change the original PSD, not the output file. But I'm no professional, so I might be missing something.
|
Any ramblings are entirely my own, and do not represent those of my employers, coworkers, friends, or species
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Personally? Not that often. But people I work with do.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Nov 2006
Location: here
Status:
Offline
|
|
Originally Posted by TheoCryst
Question time, since I really don't know: how often do people create files in Photoshop that are not .PSD files, save them, and then re-open them for further editing in PS? I realized the other day that 95% of the time, I don't export to a non-PSD unless I'm done editing. And if I do want to make more changes, I change the original PSD, not the output file. But I'm no professional, so I might be missing something.
I don't use .psd, I use .tiff
I want a document to open in the application that created it.
Everything else is just nonsense. If I want it to open in a different application, it should be me who decides so.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Originally Posted by Chuckit
Yeah, now every Photoshop-created file will default to launching some completely different program unless you change the default app to Photoshop for every one of them.
If you want .tiffs to open in Photoshop when you double-click them, you could, oh, I dunno, change the default app for .tiffs to Photoshop.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Originally Posted by CharlesS
If you want .tiffs to open in Photoshop when you double-click them, you could, oh, I dunno, change the default app for .tiffs to Photoshop.
I don't, though. By and large, I prefer all images to open in Preview because it's much faster and more lightweight than Photoshop. I only want Photoshop documents to open in Photoshop, and I don't want to have to care about stupid Windowsy details like what their file extension is.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Grizzled Veteran
Join Date: Mar 2004
Status:
Offline
|
|
Originally Posted by CharlesS
Dude, you're extremely late to complain about this one. Creator codes have been redundant and obsolete ever since OS X came out. Most Cocoa applications don't even bother setting the creator code - the only apps that actually do are older applications like Word and Photoshop that have been ported from OS 9, and you can expect those to stop doing it too as they get rewritten in Cocoa for 64-bit, since Cocoa makes you go out of your way to set the creator code, and there hasn't been any point in bothering with those things for years. So in a short time, you're not even going to have any apps that set the creator code on files at all. So why does it matter if the OS supports them?
Look, if you want to replicate the old "creator code" functionality, send Apple feedback to put an equivalent in Cocoa that would put a resource in the file's resource fork similar to the 'usro' resource, or even better, an extended attribute that will give a record of what application created it. But make it an optional setting somewhere, so we don't all get stuck with this behavior, and make it based on the bundle ID, a modern piece of metadata that applications actually use. Don't beat the dead horse of the creator code.
I am certainly not up on much (if any) of LaunchServices' internal workings, but i can observe certain things...
$ date; sw_vers
Wed Sep 9 22:14:36 EDT 2009
ProductName: Mac OS X
ProductVersion: 10.5.8
BuildVersion: 9L31a
$ type lsreg
lsreg is aliased to `/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister'
$ lsreg -dump |grep -c 'creator code'
2853
Hmm, almost 3000 lines in the LS db with the phrase "creator code".
Trying to clean and shrink the (ginormous) output a bit with something like...
lsreg -dump |grep -A9 ^bundle |egrep '(name:|creator code:)' |grep -B1 creator
...still produces a long mess. So here's just a sampling of what's there...
Code:
name: iTunes
creator code: 'hook'
name: Postbox
creator code: 'PPLM'
name: QuickTime Player
creator code: 'TVOD'
name: HoudahSpot
creator code: 'HHSP'
name: Platypus
creator code: 'Plat'
name: AppHack
creator code: 'ApHk'
name: CLIX
creator code: 'RxCx'
name: Quicksilver
creator code: 'daed'
name: FastScripts
creator code: 'Fscp'
name: Safari
creator code: 'sfri'
name: Preview
creator code: 'prvw'
name: OmniOutliner
creator code: 'OOut'
name: MoneyWorks Cashbook
creator code: 'CW2+'
name: iCab
creator code: 'iCAB'
name: iVolume
creator code: 'iVol'
name: DiskWarrior
creator code: 'DWrX'
name: Terminal
creator code: 'trmv'
name: VoodooPad Lite
creator code: 'VoPP'
name: DTerm
creator code: 'DTrm'
name: DVD Player
creator code: 'cfbs'
name: Font Book
creator code: 'ftbk'
name: GraphicConverter
creator code: 'GKON'
name: iCal
creator code: 'wrbt'
name: iChat
creator code: 'fez!'
name: Shiira
creator code: 'ShiR'
name: Firefox
creator code: 'MOZB'
name: Pacifist
creator code: 'Pax!'
Ultimately, there's a basic test... like double-clicking a jpeg. It opens in Preview.
Then, launch File Buddy and change the creator code on the jpeg (from nothing) to GKON.
(i.e., no fiddling with any OSX Get Info window "Open with", etc).
Double-click the same jpeg... and GraphicConverter opens the file.
Q.E.D.
I wouldn't say creator codes have been "obsolete" ever since OS X came out.
In fact it seems that LS gives them preferential treatment (as of OSX 10.5.8 anyway).
Or perhaps I've misunderstood the argument (in which case, apologies all around).
-HI-
|
-HI-
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
I'm pretty sure it's never given the creator preferential treatment. If the doc had a usro resource, it would use that. It went filetype default < creator < usro.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Originally Posted by Hal Itosis
Or perhaps I've misunderstood the argument (in which case, apologies all around).
You have. It's not that creator codes didn't work in 10.5 - they did. However, they were archaic, redundant, and obsolete. There exists a more modern signature for identifying applications - it's called the bundle ID, and it's been there since 10.0. It uniquely identifies each application on the system in a way that's more flexible, more scalable, and less prone to collisions than the creator code, it can be used to query the LaunchServices database to look up applications just like the creator code, and it's actually used by all OS X applications, not just ones that were ported over from Classic. The only reason the creator code was in the OS was because OS 9 had it - as soon as Classic was stripped out of the OS, there was no reason to keep it around anymore. I'm surprised Leopard even had it.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
If it were possible to mark a document with a creator bundle id, that would make sense. I don't think there is such a thing, though.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Grizzled Veteran
Join Date: Mar 2004
Status:
Offline
|
|
Originally Posted by Chuckit
I'm pretty sure it's never given the creator preferential treatment. If the doc had a usro resource, it would use that. It went filetype default < creator < usro.
Well, i meant preferential treatment over the default "Open with" (as set by the .jpg extension). Out of the tens of thousands of docs in my possession, i bet i can count the ones with a ' usro' resource on one hand. Very, very, VERY few docs have any resource fork at all (clippings and drag-n-drop url .weblocs excluded).
EDIT[s]:
speaking of things that OSX was going to make obsolete, wasn't resource "forks" at the top of that list?
[not xattrs in general, but resource forks specifically. Also, what's a good ResEdit replacement for OSX?]
This post may have some relevant info:
Print "Preview" uses Acrobat vs. Preview
[note also the gif there linked to "4 different types of PDF's"]
Even though that article is of Jaguar vintage, Leopard seems to behave the same.
If obsolete is equivalent to gets preferential treatment then, (as Gomer used to say) "Surprise, surprise".
(
Last edited by Hal Itosis; Sep 10, 2009 at 12:12 AM.
)
|
-HI-
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Originally Posted by Chuckit
If it were possible to mark a document with a creator bundle id, that would make sense. I don't think there is such a thing, though.
Right, but that's due to a design decision rather than any technical consideration. There's nothing the creator can do that the bundle ID can't - the Finder could just as easily look up an app based on the bundle ID if it were coded to do so. The reason Apple hasn't done so is because it's annoying for applications to randomly take over your documents and override your settings (it's bugged me for some time how I always had to Get Info -> Change All for virtually every combination of extension + creator code just to get documents to open with a certain app). The reason creator codes were still in the OS for as long as they were was because they were needed for the Classic environment to work right, but it's gone now, so there's not much reason to keep them around anymore. And it won't affect things much either way, since even if the creator codes were still honored, most of the apps that use them are going to get ported to Cocoa over the next couple of years, after which time the apps will only write the creator code if the developers explicitly go out of their way to do so - which almost never happens. I dare you to find a single Cocoa app that puts a creator code on files it writes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|