How not to use UTIs
John C. Welch has written an article telling you to use UTIs to replace creator codes.
It is wrong.
Daring Fireball, rosscarter.com, and (the most sober of the bunch), TidBITS have all gotten on the “Apple has abandoned creator codes, now we’re screwed, damn you Apple” bandwagon. They’re all right about one thing: Apple has dumped creator codes in Snow.
So before you panic, there’s a replacement mechanism, the UTI, or Universal Type Identifier.
No. Uniform Type Identifiers are a replacement for type codes (and MIME media types, and filename extensions), not for creator codes. There is no replacement for creator codes.
Uniform Type Identifiers are just that: They identify types of data. Using them for anything else is misusing them.
Ideally, Coda should assign an application-specific UTI for CSS files it creates.
No, it should not.
As it turns out, Coda is a UTI-aware application, and according to Coda’s info.plist file, that identifier is com.panic.coda.css.
And that identifier is wrong, because CSS is not Panic’s format.
I use CSSEdit. Currently, it doesn’t declare a UTI, but if they should follow Coda’s example, they should make one up of their own, such as com.macrabbit.cssedit.css. Now we have one type with two names. Which is right?
Suppose I write an application that accepts CSS data. Which UTI do I look for: com.panic.coda.css or com.macrabbit.cssedit.css? Should I look for both of them? What if I find both? What if a third developer releases a CSS editor? Now I have to keep up with the entire population of Mac CSS editors just to accept all the many names for one type.
The right type identifier would be something like org.w3.css or org.w3.cascading-style-sheets, following the rule that the type should be named after whoever controls it. The W3C controls CSS, so its UTI should be named after them. Some other formats, such as PNG, aren’t controlled by anybody, so they go in public.
You might point out public.html and public.xml, as both of those are also controlled by the W3C. Obviously, I disagree that these should be in public.*. But it’s too late to change them now, so we have to put up with them.
Better examples include com.adobe.pdf and com.microsoft.word.doc. In each of these cases, some third party controls the format, so they get the format’s UTI named for them. Notice that Preview does not invent a com.apple.preview.pdf UTI, and TextEdit does not invent a com.apple.textedit.word.doc UTI; they use the UTIs named for the creators and maintainers of those types.
So now we see a problem. All the text-ish files have the same type identifier: com.apple.traditional-mac-plain-text.
Because they are all the same type. And that type is named after Apple because Apple controls that format (in this case, a text encoding).
The Photoshop PNG file is typed as public.png.
There’s no such thing as a “Photoshop PNG” file. PNG is an open format controlled by no-one (or, arguably, the W3C, in which case the type should have been named for them). What you have is a PNG file that you created in Photoshop. That latter detail is irrelevant to its type, which is why HFS had the creator code separate from the type code in the first place.
If there is such a thing as a “Photoshop PNG” file (that is, if Adobe incompatibly extends the PNG format in some way), then they should assign that format its own name (say, com.adobe.png), because it’s a different format.
If you take away the creator code, you’re screwed, because all you have are the extensions.
Exactly why John Gruber, Ross Carter, and Matt Neuberg don’t like the change.
Coda CSS file props:
displayed name:"test.css", creator type:"TStu", type identifier:"com.apple.traditional-mac-plain-text",
I’m surprised you didn’t notice this. Why isn’t this file’s type identifier com.panic.coda.css?
… why aren’t any of these applications doing the right things? Pages ’09 does. It sets the type for .pages files to “com.apple.iwork.pages.pages”.
Because it’s Apple’s own format specifically for Pages. Again, see also com.microsoft.word.doc.
Unsurprisingly, it doesn’t even have a creator code.
Yeah. Cocoa makes it difficult to apply a creator code to a file and doesn’t do it automatically, so expect most Cocoa apps to not do it.
Even thought the default for the .html extension is BBEdit, the UTI overrode that. When I changed the handler for public.html to BBEdit, then the file opened in BBEdit. That’s exactly the behavior I’d expect, and it matches what you got with Creator Codes.
It matches what you got when you assigned the default handler of a file type, as well. That’s what you did the newer equivalent of.
There never was a way to set which application opened files that had a given creator code. That was what the creator code was for: Determining which application would opened the file.
Yes, Apple did abruptly kill off Creator Codes, however, they’ve been warning about that for some time now.
Sort of. They’ve been warning that they’d kill off the combination of file type codes and creator codes. UTIs are the replacement for file type codes; as I said above, there is none for creator codes.
Now, I know that ‘simple’ is a big fat lie when it comes to application development, however, at some point during the 10.5 lifecycle, all these applications should have been updated to not only support UTIs, but to use them. Instead, they all relied overmuch on FIle Types/Creator Codes …
Actually, it was more common to use filename extensions. See what I said above about the difficulty of assigning file types and creator codes from a Cocoa app. I think that was actually quite rare, simply because filename extensions were so much easier.
… and now that those are gone, well, the OS does what it can with the information it has available.
No, it doesn’t. The creator code information is still available, and the OS ignores it. The OS now only uses type information to determine how to open a given file, except for files that the user has assigned a specific application to.
Oh, and what about when you change a file association in the Finder? Well, unsurprisingly, the Finder cheats. It adds a resource fork to the file with the path to the desired application coded within. … [M]aybe the Finder could start doing the right thing too?
Agreed. I say it should set the file’s creator code.
Incidentally, I tested in Tiger, Leopard, and Snow Leopard, and Finder did this resource trick in all three versions. If the Info window ever did set the file’s creator code, it hasn’t done that for many years.
If the only way to have a unique UTI associated to a file is for that file to use a completely unique file extension, then WHAT THE FUCK GOOD ARE UTIS? Fucking seriously, why the FUCK bother? BBEdit creates TEXT FILES. Does Apple seriously expect that Bare Bones, to properly use UTIs, is going to now create a .bbedittext extension, a .bbedithtml extension, a .bbeditohmyfuckinggodwhatthefuckisgoingon extension, then make you EXPORT to ‘standard’ extensions, just so you can know a file created in BBEdit will open in it?
And now you know why smashing type information and creator/opener information into a single value is a bad thing.
If this is what Apple is pushing, then everyone who signed off on non-settable UTIs is a fucking idiot…
There is no reason why the average user should be able to change the type of a file. If they created an HTML file, it’s an HTML file, and there’s no reason for a user to be able to set it to anything different unless they really know what they’re doing. (I’ve done it, and I’m assuming you have, too. We’re exceptions.)
What you want to do is to change which application opens the HTML file, and that is completely separate from the fact that the file contains HTML.
September 22nd, 2009 at 20:54:28
Isn’t it enough, then, for a creator app to set that Finder information in the resource fork when it saves the file? It’s not the best solution, but it’s at least less bad than the current situation in Snow Leopard. The big guys like Adobe or Microsoft will not do that soon enough, but small software companies can.
September 22nd, 2009 at 21:16:48
There is no public API for this. A private function can change or go away at any time, at which point all apps using it stop working. If you’re lucky, the app you’re using will simply not be able to set the file’s owning app. If you’re unlucky, the app will crash after saving.
September 22nd, 2009 at 21:22:23
So, maybe a UCI to match? Uniform Creator Identifier? And just use that com.apple or com.barebones.bbedit or com.panic.coda scheme that has been well-established in the land of preference files? Or is enough creator information in the Spotlight-readable metadata already?
I usually use mdls (in Terminal) to look at the UTI (kMDItemContentType) and other stuff like kMDItemContentTypeTree and kMDItemKind and kMDItemFSCreatorCode and I thought of that stuff as immutable without re-saving the file. But no, the Snow Leopard Finder actually seems to be CHANGING some of the document’s metadata on an open, notably the ‘File Kind’, aka kMDItemKind. I double-click on one html file with kMDItemKind= “BBEdit text document” and shazam, it becomes kMDItemKind = “HTML document”. Yet these are preserved: kMDItemCreator = “BBEdit 6.5” and kMDItemFSCreatorCode = “R*ch”.
An odd kind of obliviousness, this Cocoa Finder has.
September 22nd, 2009 at 23:47:57
jcburns: A separate “UCI” wouldn’t be needed, since applications already have bundle identifiers. A non-fragile application binding (i.e., a sensible replacement for ‘usro’ resources) would really need more than that, though; the bundle identifier, application version and an alias (or “URL bookmark”) to the chosen instance, for example.
kMDItemKind changes because it isn’t really an attribute of the file. It’s generated on the fly when requested and reflects whatever type and creator information is available and respected by the system – extension, type code, and ‘usro’ resource.
September 23rd, 2009 at 00:54:02
A way to use UTIs for coding—without breaking things, as I see it, though I am merely presenting this rather than advocating it—would be to use com.barebones.bbedit.txt as a subtype of public.plain-text or whatever. Can read in public.plain-text, but uses metadata API to set the kMDItemContentType after saving.
Personally, I would prefer something like an “always open in this app” checkbox in the Save dialog. Same thing as the Finder pop-up, effectively, but set at save time. It would of course be sticky, so if I save one document with the box checked, the next document I save with the same Save sheet will “open in this app” as well.
September 23rd, 2009 at 03:25:53
Jordy, that would break things. There are lots of subtypes of public.text, and new ones are created all the time (even if most don’t have their own UTIs). As en example, imagine I created a text-based markup system called AhruML, and gave it the UTI com.example.ahruman.ahruml, a subtype of pubic.text.
In the current system, I could then write an app that only deals with com.example.ahruman.ahruml, and also edit my files in any text editor that supports public.text.
In the subtypes-for-creators scheme, if I then tried to bind it to BBEdit, it would either fail because BBEdit doesn’t have a subtype for AhruML, or change it to com.barebones.bbedit.txt and break my app that’s expecting com.example.ahruman.ahruml (thus eliminating one of the main points of the UTI system).
It’s *possible* to hack creator information into UTIs, but there’s no actual advantage to it – it would require changes to all apps that currently use UTIs correctly, and changes to how the system deals with UTIs internally. If Apple desired to have a new way of binding files to applications (which is clearly not the case), using a separate piece of metadata would be conceptually cleaner with a clear separation of concerns, probably easier to implement in the system, and definitely easier to implement in applications.
September 23rd, 2009 at 12:01:22
Cross posting from my comments to bynkii.com: for what it’s worth, I agree with you (Peter) (and with Jens too), and told John Welch as much in the comments to his entry that responds to this one: http://www.bynkii.com/archives/2009/09/oh_cthulu_here_we_go.html#comment-17223576
As I’m at it, I should mention that practically all Spotlight “metadata” is in fact synthesized from a few well-known pieces of metadata (e.g. type code) or from the file contents (say, EXIF). Very little has its own dedicaced storage.
September 23rd, 2009 at 13:16:58
Don’t the people who want creator-specific bindings realize what a minority they are? Most people always want the same files to open in the same program, because most people aren’t coders or designers. It’s annoying as hell when a jpeg opens in Photoshop or whatever.
September 23rd, 2009 at 13:31:35
Peter, one detail you have missed is that UTIs are hierarchical. Panic can define an application specific CSS UTI which extends the public CSS UTI. Any search for CSS would yield the public CSS and all derived types, including Panic’s CSS UTI. Extending an existing UTI provides more type information about the file, and should not be seen as mutually exclusive with the generic type.
September 23rd, 2009 at 13:42:45
To expand on Jhn (comment #8)’s point, creator-specific bindings are doubly annoying when they travel from someone else’s computer. I’m glad to see the back of them.
I remember the bad old days, downloading a piece of software from a company and double-clicking their ReadMe.html file only to have it open in BBEdit instead of a browser, simply because the developer used BBEdit to create it.
September 23rd, 2009 at 13:50:19
Jeremy Cloud: That only works if there is a public.css UTI. Currently, there is not, which means com.panic.coda.css has to descend from public.text.
September 23rd, 2009 at 14:16:41
Jhn and Chris are wrong here. There may be situations in which the presence of creator codes didn’t give the best experience in the past, but those mostly arose from the file being published by someone (e.g. a software company) who didn’t care enough about publishing their files in an adequate way. One could perhaps think about it being inadequate to transfer between users, but that would certainly require some good thinking beforehand.
For my personal usage, however, this is completely irrelevant. I find it completely illogical and inconvenient that a HTML file I saved in Coda should open in Safari when double clicked. The various text files there are serve as another example: I may use different editors for them and I do expect those file to open again in the correct application.
Creator codes also had the potential to solve other problems which were introduced by applications not using Type codes but relying on an ‘extension’ at the end of the file name, thus opening themselves to all sorts of stupidity and confusion. How many applications write files whose names end in .dat, .log, .csv or .text? Wouldn’t it preferable to open each of them in the application that can handle the specific file type in question? I thought so.
September 24th, 2009 at 05:00:45
What we really need is a better representation in HFS+ for small xattrs; presently they require a second lookup (into the attributes B-Tree) to grab them, which makes them inefficient for this type of thing. That’s probably one reason Apple didn’t “just” do that in Snow Leopard.
Then we could have two xattrs, one for the creator and one for the file type. The creator xattr at a minimum could be a bundle ID, though ideally it should be a little more comprehensive. The file type xattr could hold the UTI. And we wouldn’t need the resource fork any more for this purpose.
Perhaps the solution here is to add a new type of file record in HFS+ that strips out all of the historic Finder information and related junk and adds in a new small-attribute area… of course, it’d be a pain for disk utility software in the short term, but in the long run it would seem to be a win.
September 24th, 2009 at 22:12:40
In reply to comments # 2 : actually, there is a documented way to set the default application for a file, using Apple Events and the “set default application” command in “System Events”.
September 30th, 2009 at 16:45:48
Apple is wrong about this, and only they can fix it. UTIs are not stored on a per-file basis; until they are there is no possibility of them replacing the functionality of the type code and/or filename extension, let alone the creator code. The OS synthesizes a UTI for a file by reading the extension or type code, offering a more convenient and less fragile way for an app to specify a file of a particular format.
The Open With functionality of the creator code has been a unique Macintosh superiority since 1984, though Apple should have provided a user interface for setting or clearing it. Open With allows customization of the user experience for whatever reason — why do some people insist that your computer should be restricted to operating like any other? (Other then Microsoft, I mean.) Ignoring the creator code makes your current files behave differently, degrading the user experience and even risking data loss (if, say, you accidentally save a Nisus Writer RTF file that unexpectedly opens in TextEdit). And why does Apple have us to create resource forks for all files for which we set Open With when they recommend moving away from resource forks, and the creator code slot will exist as long as HFS+ (or longer, as Apple currently implements it on other filesystems)?
Have they been infiltrated by Microsoft?
October 1st, 2009 at 08:25:25
This is a typical problem of 5% of the people not being happy with something that makes the other 95%’s lives better. Think about this from the average user’s stand-point. When they double click a text file it should open in the “text app”, two different text files shouldn’t open in two different apps.
Seriously though, how many of us create (and then want to reopen) the same type of files in more than one app? Are you really opening CSS files in 3 different apps and need to keep the creator associated with the file? As a fairly technical person, I never trusted my file types and would always “open as” or drag files to the dock to open them. I’m actually happier with this system… now I can set my CSS files to open in BBEdit, and I ALWAYS know a CSS file will open in BBEdit, not TextEdit, or whatever else. This is simpler and clearer, get over it.
October 1st, 2009 at 08:33:12
Regarding hierarchical UTIs, I believe they could actually be used as a replacement for the creator code, but only if a) there’s a way to store a file’s UTI separate from the file extension, and b) there’s a standard way of specifying public UTIs for common file extensions.
Neither condition is currently true, so this is a moot point. b) gets around the fact that not all “standard” types have an existing public.* declared type, such as is the case with CSS files.
But if there were a way to store a file’s UTI, and a way to specify that all ‘.css’ files were of type ‘public.css’ as a subtype of public.text, then Panic could set CSS files it creates to have a UTI of e.g. ‘com.panic.css’, which is a subtype of ‘public.css’, which is a subtype of ‘public.plain-text’. BBEdit could still open the file since it can open plain text files.
October 1st, 2009 at 09:03:27
“How many applications write files whose names end in .dat, .log, .csv or .text? Wouldn’t it preferable to open each of them in the application that can handle the specific file type in question? I thought so.”
Sometimes maybe, but usually when I open a .log file, I want to open it in a text editor not in whatever application wrote it.
There are situations where creator codes are useful but also a lot where they are downright annoying. I prefer the predictability and consistency of file extensions. If I want a specific app to open a file, I simply drag it to the Dock.
I constantly re-open the same file in multiple applications. Xcode has a very nice code completion. TextWrangler has nicer syntax highlighting and the commenting command works better.
I am about as likely to open a html file in TextWrangler as in SubEthaEdit. Where I want to open a file is pretty uncorrelated with where I created it for all those general purpose file types.
October 1st, 2009 at 09:10:41
I completely agree with Jon Sweet – that this is a problem affecting a vocal 5% minority that is a major improvement for the other 95% of us. Keep in mind – I’m a coder. I’ve used macs since 1985. And creator codes -suck-. The entire notion of being associated with a creating app is terrible and unintuitive, because you can never really tell which app is going to open something – it’s so bad that I’ve sunk to opening nearly every ‘dangerous’ type – a type I have multiple apps for, via the right-click open-with menu, or via a drag to a dock icon. Absolutely the worst is that the setting to force all documents of a type to open with a certain app simply doesn’t function. It ignores any document with a resource fork, and has done so since 10.1.
I want to congratulate apple for doing the right thing, and clamping down on a major UI flaw even if people bitch about it for a bit.
Now, if they can just get rid of disk images as the normal app distribution method, we’ll be getting somewhere. :P
October 1st, 2009 at 09:13:15
The problem I have with the creator code way is that it assumes that double-clicking on a document icon means “edit” and also “edit with the thing I created it with”. How does the system know that I’ve finished authoring/editing a document and now want it to just be viewed? It doesn’t.
Using the JPEG example, say I “create” one by exporting a photo from iPhoto as JPEG. I don’t want that opening in iPhoto. I most often want to simply view it, so waiting for Photoshop to load is not fun. Right clicking to “open with” 95% of the time is not fun. The savior in the mean time has been QuickLook. I just press the spacebar to view the document, double-click to edit. My wife would be annoyed if all the HTML files I created in [geek_text_editor] opened in that due to a creator code rather than opening in Safari.
Complain all you want, but we are Mac users too and the old guard Mac users are not in charge of how the Mac works, Apple is.
October 1st, 2009 at 09:39:18
Put me down as a long-time Mac user who is glad to see creator codes die. What app wrote originally wrote a file usually has nothing to do with what app I want to open it, even more so today where most of the files we work on are common interchangable formats like JPEG and HTML. Jon, Richard, and Ryan have said it all for me.
October 1st, 2009 at 10:04:38
“Suppose I write an application that accepts CSS data. Which UTI do I look for: com.panic.coda.css or com.macrabbit.cssedit.css? Should I look for both of them? What if I find both? What if a third developer releases a CSS editor? Now I have to keep up with the entire population of Mac CSS editors just to accept all the many names for one type.”
I don’t think you’re supposed to look for specific UTI’s when accepting generic data types, unless of course that’s what you’re looking for. You look for ‘public.css’ and any UTI that conforms to it will be available to you. So while com.panic.coda.css is a specific type, it descends from and conforms to public.css.
From Apple’s Developer Page…
“For example, if your application can open any type of plain text document, then you simply specify public.plain-text (also known by its symbol kUTTypePlainText) in the imported types dictionary within your application’s Info.plist. Now any UTF-8, ‘TEXT’ (a Mac OS 9 OSType), ASCII, and other text file can be dropped on your application for opening. If your application instead only handles specialized types of text documents, you can specify one or more subtypes rather than public.plain-text, and only those subtypes will be passed to your application.”
October 1st, 2009 at 10:44:03
LRhodes: “Have they been infiltrated by Microsoft?”
Not exactly. What happened is when Steve Jobs came back to Apple, he brought his NeXT crew with him, and at some point thereafter, the last pre-98 Apple developers were gone. Thus Apple *has* been infiltrated, by NeXT, and NeXT was always more like Windows than it was like the Mac — e.g. its use of simple DOS-style file extensions rather than the Mac’s far more sophisticated type/creator code metadata system. The people now working at Apple never used the classic Mac OS, and, like the recent Windows switchers who now make up a large (majority?) percentage of the Mac user base, they don’t understand why old-time Mac users are upset at the loss of some of the best parts of OS 9 & earlier.
Remember, Steve Himself never used the Mac between 1986 (that would be Macintosh System Software v. 1.1?) and his return in 1997 — and I’ve read that even then he pointedly brought a NeXT computer with him, and used that until OS X was functional.
I remember when screenshots of OS X first appeared in Macworld; clearly it was another OS entirely, with an afterthought Apple logo pasted on — in the middle of the menu bar, with no function beyond the cosmetic appearance. It took a huge howl from the Mac’s installed base to get a sort-of, non-configurable Apple menu into OS X. And ever since then it’s been the same story. Bit by bit, all the most clever elements of the classic Mac environment have been dropped.
A good example is what happened to AppleWorks, one of the best applications ever on any computer platform. But it wasn’t developed by the NeXT developers who now run Apple, they’d never used it, they didn’t understand what was so clever about its seamless integration. To today’s Apple, Microsoft Office is the “standard” to meet and beat, thus iWork: like MS Office, a “suite” of separate, basically unrelated apps tossed together into a bucket with some after-the-fact interoperability, rather than a really integrated set of capabilities like AW. iWork may be a better Office suite than MS Office, but it’s *not* a replacement for AppleWorks.
Certainly the classic Macintosh type/creator code system was not perfect, and yes, it’s true that computer use has changed significantly in 20 years so something better is needed; but what Apple has done here is not an improvement. I’m not a programmer, most of this discussion of UTIs and their capabilities/possibilities is beyond me. But why, if UTIs really are the solution, is there so much disagreement about how they work? Is it just that everyone who doesn’t think they are a replacement for creator codes is plain stupid?
All I know is what I read about the change in Snow Leopard (which I haven’t tried yet myself, in great part because of all the problems I’m reading about) dismays me. It’s another devolution of what made the Mac special, pushing everyone down to the lowest common denominator established by Windows, wherein, I gather (I’ve never used it, been Mac only since I got my first computer in 1988), all .jpgs, for instance, open in the same application, since the OS has no way to tell them apart — just like in the new, improved OS X.
The other thing I find of interest in this and many similar discussions is the attitude of the Apple apologists — those who think the change (and anything else Apple does) is a Good Thing. It’s always “It works for me, I don’t care if it doesn’t work for you, get with the program.” It’s exactly the same in discussions about matte vs. glossy displays. What about choice? I’ve never seen anyone who prefers matte displays proposing that everyone should have to have matte displays; all we want is a choice. (Similarly, next time I get a new Mac portable I’m going to have to switch from the 17″ model — of which I’ve had three since 2005 — to the 15″. Steve is 12 years younger than me; apparently he has no difficulty reading the tiny type on the new 1920×1200 displays, so that’s what everyone gets. No choice.)
Surely there’s enough programming expertise at One Infinite Loop to figure out a way to allow users to either (a) have all documents of a type open in a single application, unless individually, manually set to another; or (b) retain the old system where a document opens in the application that created it, again unless individually, manually set to another app. What’s wrong with choice?
Steve is certainly a genius in many ways, but he does have an annoying tendency to believe that since his way is obviously the best way, no intelligent person could possibly want to do it any other way. This attitude soaks down from the top.
October 1st, 2009 at 11:32:08
I think we may need more than a replacement for creator codes at this point. To be frank I didn’t like the old behaviour and I like the new one even less.
What I’d love this scheme to work as would be to separate exporting a file from saving it in the creator application. Exporting would be for use with other apps, and should be handed by the os to the UTI handler. And saving would be for use with the app, and should open in said instance/version of the app.
How this would be done without the whole dev community supporting it and Apple releasing public APIs to do all of that is beyond me. But maybe someone could come up with a solution?
October 1st, 2009 at 12:44:56
godDLL: Seems to me you could do that by simply having the Save command let the creator information and the Export command not do that. With no creator set, the file would open in the default app for its type.
October 1st, 2009 at 13:19:53
Most here already know this, but clearly a few above don’t know. The problem is with the 10.6 POLICY Apple has chosen. They didn’t have to do this.
For details, see the article John Siracusa wrote here.
http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars
If most of the the policy could be user set, we wouldn’t be having these discussions. Or, at least, they’d be less intense. As an example, if you could just go to “system preferences >file system >settings policy, and make change thus, and so”. Then everybody’s happy. Keep creator codes (an option could even make them permanently ignored), UTI, 8.3, or anything else.
Customize your system OS per this example, or in any other order you wish:
1) open file abc in application xyz (if set)
2) open file per UTI
3) open file in app creator
4) open file per file extension
5) open file in last app used
6) allow/do not allow any user set file info to override system wide preferences
7) anything I’ve forgotten
8) ASK
9) API for additional criteria. (As Apple, I’d avoid this option like the plague…)
Put a check box telling the system ignore all items but 8.3 and ASK, if you wish.
e.g., let it degrade gracefully. Unless the user sets the policy to do so, don’t ignore included file info. The OS POLICY should use all file info (in whatever order Apple desires) as a default. Then, let the user change the details as needed.
This way, everyone can set the system to open a file using the info available in your prefered order.
The system’s POLICY is what’s whacked. 10.6 should not be ignoring file info unless EXPLICITLY TOLD TO to by the user. I understand Apple’s wish to simplify the system. Many users don’t have any need to know about this, but if they ask, it’s there. Just make sure this is clear to developers, with clear API’s to use in carbon, cocoa, 32bit, and 64bit. This isn’t something to be used for forcing an upgrade (or downgrade in this case).
October 1st, 2009 at 13:21:05
This issue clearly shows a divide in preference, with power users on both sides of the fence. So having it as one checkbox in Finder would be a perfect solution.
October 1st, 2009 at 13:51:19
Clarification:
Inside System Preferences, you should be able to set the system wide policy.
That includes a user adjustable priority for all elements per a configurable list as shown in reply #26.
Second, a check box next to each item, for telling the system to ignore that info completely (with apropriate warnings). Individual file default app changes would still be available in get info, and when right clicking (unless disabled in system preferences).
October 1st, 2009 at 15:16:59
As I commented on the Siracusa article, there are TWO problems Apple is confronted with in this debate:
#1 Apple has embarked upon a foolish path neglecting Best Practices regarding metadata
#2 Even though their solutions sometimes make one doubt it, OS X -is- a multi-user environment and some of these “preferences”/mechanisms don’t deal very well across multiple users nor mesh easily into HFS
The first problem, metadata, is something that Siracusa has bitterly complained about since just about day 1. And I’m right with him. Almost every bone-headed design problem I’ve ever encountered watered down to missing information that was once in hand. Ignoring and destroying factual and near-factual information about a file is just plain dumb, and that’s what Apple is doing by relying on TLEs. I mean, c’mon, TLEs have been a dumb idea since their inception. (A file’s NAME is somehow supposed to completely DEFINE it??? Imagine if people were treated in such a way, Joe The Plumber notwithstanding.) The ‘creator’ of a file is pertinent information, final. How that information is used is a different point. The fact that Windows Explorer can display and sort audio files by ID3 information yet the Finder cannot, embarrasses me. Really. The fact that Apple so “doesn’t get” metadata that their “special” apps are the only ones that act upon it is beyond disappointing…it is, in short, a flawed design philosophy.
The second issue comes into focus as “solutions” to the issue at hand start to be investigated. All the “other side” commenters here are right: it is confusing to have files open in–or attempt to open in–weirdo apps. Which is why a second piece of metadata is required: the Utilizer code. A file necessarily has a TYPE which defines its internal structure, a CREATOR which can be used to modify/edit that structure, and a UTILIZER–the app that you want to open the file, for whatever reason. That could be further editing, ongoing editing, viewing, etc. But that is, typically, an INDIVIDUAL choice. Hence that piece of data should be attached on a user-by-user basis, not stuck inside the file or a file-system fork. Additionally the UTILIZER could be assigned system-wide. As Siracusa pointed out, with that much metadata, a definable policy could then be used to replicate ANY of the “preferences” mentioned in this debate! (As an aside, the act of “exporting” would necessarily be a mechanism by which a file’s CREATOR would undergo change…when a Web Designer finishes a site in Dreamweaver and exports it, the HTML files would then become “owned” by a public UTILIZER, a web browser.)
I think Siracusa’s, and ilk’s, argument is NOT that what Apple has done is right/wrong from the -user’s- perspective (John isn’t saying if you LIKE this way you’re dumb). What he is saying is that by going this route of fundamentally ignoring the merits of good metadata usage, Apple has now committed an act that has become very hard to undo. It is though, quite simply, Apple has said metadata be-damned. By not implementing Cocoa APIs that even PERTAIN to manipulating creator metadata on a file in 10.6 (the beneath the hood update, remember) yet still making the change to forgo the only creator metadata mechanism left, that’s pretty much the only conclusion to be drawn.
However, given the criticism that Apple has been getting for the past several years from Rixstep over UNIX file permissions and the liberties that Apple has been taking with them, I think we are seeing through to Apple’s true colors: they don’t care. Some of these changes are so specious and arbitrary–I’d say amateurish–that it belies a complete lack of an overriding design principle. Which is odd, given the thought behind technologies such as Grand Central, etc, from the same engineering division.
October 1st, 2009 at 15:17:47
As I’ve written elsewher, it’s not because someone imagines being in a majority (and where the hell did you pull that 5%/95% stat, other than your ass?) that this majority automatically gets to “win”, because even if it’s actually a majority, if the policy is a huge inconvenience for an important minority, is it actually the best policy? Not to mention giving people what they say they want does not give them what they actually need.
Also, has any of you thought about why some people are upset that files of the same type get opened by different applications, but have no problem with files of different types being opened by different applications? Think about it: they consider the former the same, because they have the same icons. QuickLook is fine and all, but I consider the loss of the information of what is going to open the file a regression; and obviously no policy is going to match everyone’s expectation (and that’s expected, that’s why it’s a policy, otherwise we’d call it something else), and if you can predict using the icon (or something else) a policy/expectation mismatch is only one extra drag and drop in this particular case, but if you can’t, then this mismatch becomes a huge inconvenience as the application that opens isn’t the one you expected, and you now have to suit it and drag and drop the one you wanted; the result is much more tension on the policy, which would pretty much need to read your mind (even if the policy can be set by preference) to not infuriate anyone, and a more heated debate than is healthy. So sure, the icons have become poorer in information with QL, so now let’s just make the policy poorer to match. But why not the other way round?
October 1st, 2009 at 18:53:17
The worst part of this debate is we have been having it for about a decade now and no solution. Apple should have fixed this. I shouldn’t have to see a difference between Leopard and Snow Leopard. This should all be developers only who are working on this. Rebooting into Snow Leopard and all your document icons have changed is unacceptable.
By now, they should have created a new way to do all this that is so much better in so many ways that everyone who likes either past system is satisfied and productive with the new one.
> separate exporting a file from saving it in the creator application
This is already how the guidelines are structured, but very few developers do this. Apps seem ignore Creators or use them all the time.
October 2nd, 2009 at 09:57:22
Ahrman @6 says:
In the subtypes-for-creators scheme, if I then tried to bind it to BBEdit, it would either fail because BBEdit doesn’t have a subtype for AhruML, or change it to com.barebones.bbedit.txt and break my app that’s expecting com.example.ahruman.ahruml (thus eliminating one of the main points of the UTI system).
I don’t see this. Your file would in this example would be a public.text (its type, so any text application knows it can edit it), perhaps also a public.text.frob-ml (some imagined well-known markup subtype, which only fancy text applications can frob) and also a com.example.ahruman.ahruml (your private sub-subtype, which only your app knows what to do with). You have your preferred AhruML editor installed, so this file will open in that editor for you. If AhruML catches on and someone else makes a competing editor that understands it, this file might open in that editor for me (just as in single digit MacOS some competing app might hijack your creator code for me). More likely, I don’t have an app that understands AhruML, so your file opens in my favorite FrobML editor, or if I don’t have one of those, in my favorite text editor. So far this is just like creator codes, except that we can have many hierarchical decision points (in my example, three) instead of the two that type/creator enforces.
So now, as in your hypothetical, let us suppose that I deliberately try to bind this file to BBEdit — as you say, I would change its sub-subtype to com.barebones.bbedit.txt, a subtype of either public.text or (if BBEdit groks FrobML) of public.text.frob-ml. This, I claim, enforces correct behavior. Henceforth, the file is associated with BBEdit, and if your AhruML app tries to open it again, we have lost the knowledge that it was once a com.example.ahruman.ahruml file — it’s just a generic text subtype FrobML, which AhruML knows how to read and knows how to hijack back again.
You might claim that we have lost something, because AhruML files have special gifts unknown to generic FrobML, and after BBEdit stole the binding your app has no way to know that it used to be AhruML. This is a feature, not a bug. As soon as BBEdit took over control of the file, while ignorant of its ahruml-ness, it can be assumed that BBEdit may have screwed up the content in a way that makes the file broken AhruML. BBEdit has only promised to understand text, and the FrobML subtype of text, and so what BBEdit touches is text, dialect FrobML, subdialect “BBEdit style FrobML,” no matter what it was before BBEdit got involved.
The UTI system provides an infinitely extensible, hierarchical means of identifying everything about the type of a file, and allows partial public and partial private knowledge to coexist within that hierarchy. The single-digit MacOS legacy claim here appears to be that creator/opener is a different kind of thing than file type, rather than the deepest subtype in a file type hierarchy. I just don’t see what this conceptual model buys you; it seems to me that hierarchical subtypes do all this and much more, and are conceptually cleaner. This is a car, it’s a yellow car, it’s a yellow sports car, and it’s my yellow sports car. When I transfer title, the innermost subtype changes, and the new owner puts maps in the wrong glove compartment. If he transfers title back, it’s still a yellow sports car, but I can’t assume it retains the map storage properties that make it a my yellow sports car. And, especially, if it started life as a “Ferrari yellow sports car” (creator code!), I can still keep that code by promising to understand it (I read the whole owner manual, it’s now a “my Ferrari yellow sports car”) or I can replace that code by ignoring it (I don’t know Ferraris too well, this is just a “my yellow sports car”). When I take it in to the shop, Ferrari can infer by the presence or absence of their subtype whether I was aware that the car was meant to be treated like a Ferrari.
In short, creator codes capture a particular sort of metadata: this file, in addition to everything the type data tells you, came from app X. Creator subtypes can capture exactly that data, and also an additional useful datum: this file, in addition to everything the coarser type data tells you, came from app X and has never been hijacked by any application that was ignorant of app X’s special subtype enhancements. This looks like a pure win, even for hardcore type/creator fans. Please, tell me what you lose.
(Note that, for this to work, any application that creates files should characterize those files in the UTI data by maximally informative hierarchical public types and then, at finest level, by its own private “creator” type. Also, apps that rebind other apps’ files should adhere to the convention of retaining type information they understand, and overwriting private “creator” subtypes that they don’t understand, while apps that simply display or nondestructively edit other apps’ files should leave the creator subtypealone.)
October 2nd, 2009 at 10:08:55
obviously there are flaws to the creator concept, and without the hutzpa to really clean things up and launch a new paradigm, Apple defaulted to a simpler, but still quite flawed concept
as both a designer and a coder, i’m sad to see creator codes go; but for years now Apple has junked up the system enough that i have been using drag & drop (first to DragThing, then to LiteSwitch, rather than Dock) because of how many files i receive from which HFS metadata has been stripped, for which it was never present, or where it is incorrect for my environment
i can envision a better solution involving multiple attributes — perhaps type, editor, local-editor, viewer, local-viewer, quick-viewer, etc. — plus a more evolved mechanism for acting upon a file — maybe separate gestures for view and edit; that’s not a fully formed idea, but an example of what i think is missing: articulation and handling of the use-cases of people acting upon files; currently drag & drop comes closer than double-click or even Open With to efficiently addressing my needs; i would even propose removing double-click, as it is a crutch that makes user thinking too simple — the idea that one can simply “do the file” and the right thing will happen is like a language with only one verb; but then i think that Apple is nowadays really embracing the crutch-ness of its OS
OS evolution is really too slow to catch up with, and perhaps help define, the growing non-verbal language we use with computer interfaces; OS designers should look at how the Web experience is evolving at a much faster rate, and also at the fundamental thinking shifts that are happening with the generations that have grown up with GUIs and mobile devices
October 2nd, 2009 at 10:12:45
This is a car, it’s a yellow car, it’s a yellow sports car, and it’s my yellow sports car.
I should perhaps have been clearer here: I was thinking of myself as a potentially hijacking editing app, not as the user. (You could imagine a scheme in which user file ownership was itself a sub-subtype, still deeper than file creator, but even lowest-denominator filesystems have native file ownership, so that’s a bridge we need not cross.)
So, in the above analogy, imagine that the car is a “Joshua’s discount garage yellow sports car.” Joshua’s discount garage bears a relationship to Ferrari analogous to the relationship that BBEdit bears to the original creator app when it rebinds a file.
October 3rd, 2009 at 11:01:27
Both 10.5’s usage of creator codes and 10.6’s new behaviour have pros and cons. However, it’s really a question of _how_ the system uses creator codes, not whether it has them. Having a creator code is great. It gives you something to base a decision on. The HFS type and creator are/were great. The former gives the format of a file, the latter says who created it. From that info, the system can decide how to open the file. It could use that info in it’s decision or not. But having that info is important. And these days we rarely have it. UTIs are great and all, but they are not actually associated with the file on the disk. They are _derived_ from extension and type. This fails for extensionless files and fails when several different formats use the same extension (.img, .hdr, .dat, etc.!) A better UI needs rich data to make decisions upon. We need filesystem metadata! Some that could help: a) the UTI of the file format b) the bundle identifier of the app that created the file c) the version of that app d) the app that last edited the file e) etc. Were this info associated with a file, the system could better decide how to open a given file. And there’s more info available for advanced user customisation.
October 29th, 2009 at 10:05:45
What I want:
1 – when I “Save” a file, I want it to open in the same app it was saved. When I “Export” a file, I want it to be opened by the default handler of that type.
2 – that Apple and the developers sort it out. I’m postponing upgrading to Snow Leopard and buying any new Macs (except for a Mini Server) for as long as I can just for that reason.
Some people can say “You’re not upgrading only for that?”, well, since I don’t need to upgrade for any reason whatsoever, doing that and breaking my workflow for no reason at all would be just stupid, no? ;)
November 10th, 2009 at 22:36:33
A small quibble; it’s actually not all that difficult to set the creator code in a Cocoa-based app, or at least in a document-based one. It’s a simple override on a method in NSDocument.
See here: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Documents/Tasks/SavingHFSTypeCodes.html
November 10th, 2009 at 23:56:15
BJ: Sure, but even that small cost stands in contrast to *free*. Cocoa will set the correct filename extension for you, but it makes you do the work to set a file type.