Inside Snow Leopard’s UTI: Apple fixes the Creator Code

September 22nd, 2009

Daniel Eran Dilger

Snow Leopard’s abandonment of Creator Code metadata, used to open a file with its creating application, has some users are worried that Apple has killed off a core Mac-centric feature. Instead, Apple has invented a superior alternative for the old Creator Code in order to support a variety of new features. Here’s why, and what the new Uniform Type Identifiers offer.

Back in the early 80s, Apple developed a variety of unique conventions to make the Macintosh intuitively easy to use, almost to a magical extent. One example pertains to invisible file metadata that helped the system identify documents using Type and Creator Codes.

Each file was tagged with both a Type and a Creator, allowing the system to distinguish between applications that could open a file and the default application that should open the file. The Finder could also use this invisibly associated file metadata to present custom file icons for different files of the same type but created by different applications, such as two JPEGs, one saved by Graphic Converter and the other by Photoshop.

The Finder maintained simple associations between applications and files, so that any document created in Word would open automatically with Word, and each of several different text documents would each open with the application that was used to create it. In the days when users had a few simple, monolithic applications, this Type/Creator convention made sense.

On DOS and Windows, the operating system could only determine how to open a file based on its file type extension, which was explicitly part of the the file name: myfile.doc. DOS and Windows were helpless to offer the user any assistance in knowing what application originally created a given file, unless the file were saved to a proprietary format that only one app could possibly open. In that sense, Mac Creator Codes encouraged the use of common, interoperable file types while still associating certain files with a specific app.

Leaving the Mac island

The Creator Code convention worked well until documents began moving to and from other platforms, such as being saved to a DOS disk or a Unix-based file server, or via email or the web. DOS and Unix ignored the Mac metadata, so they didn’t know how to open the files received from Mac users, as those files typically lacked the simple file extension that those other systems required to interpret the file’s type.

Additionally, since those platforms also scrubbed away the Mac metadata, files copied to and from a non-Mac savvy platform couldn’t be correctly identified or opened on the Mac anymore either. With Apple’s magic removed, the files just sat there with blank generic icons, and the Finder acted just as helpless with them as Windows. The problem for Mac users was eventually solved by packaging the Creator Code information to withstand transport on a non-HFS formatted disk. That didn’t help Mac users who needed to send their files to users on other platforms however.

The common solution to that issue came to be to assign Mac files redundant information: both Type and Creator codes as well as a file extension. On NeXT and later Windows, files were given file extensions only, as there was no underlying file system support for Mac-style metadata for Unix or DOS. NeXT’s impact on Apple was particularly evident in the shift away from Creator Codes and toward file extensions.

Old time Mac users often looked at file extensions as an ugly and unnecessary feature required only to allow Macs to interoperate with the filthy masses. So, when Mac OS X arrived with support for the old Mac metadata but with new guidelines from Apple mandating that developers also use NeXT-style file extensions to express type, there was consternation that the Mac was losing the things that made it special.

Complaining about the end of the road for Creator Codes fit in with unrest about other changes afoot at Apple, such as the loss of the Spacial Finder (the idea that you shouldn’t be able to view a folder in the Finder in multiple views at once; that files should be locked into the view you last saved and stay there until you modify it).

Why Creator Codes Died

However, Apple didn’t schedule a deprecation of Creator Codes just for fun, or just to be lazy, or just to fit in with lowest common denominator operating systems. Type and Creator Codes simply weren’t good enough to support new OS features Apple had on the drawing board. Rather than trying to get by with doing less, Apple was set on doing more, and Creator Codes weren’t up to the task.

There are lots of places where the operating system needs to handle advanced data type management which transcends the basic file Type and Creator Code system developed for identifying documents on the original Macintosh nearly 30 years ago. The system must also do this in a way which remains compatible with the file type extensions in use on other platforms.

Type and Creator Codes each used four-character labels, limiting the potential for expansion. That was an improvement upon the DOS idea of 8.3 names, which truncated documents, executables, and JPEGs to cryptic, three letter .doc, .exe, and .jpg file extensions. However, creating a new Type or Creator Code required registering with Apple, because there was a finite number of expressive codes available between 0000 and ZZZZ.

Today, the app used to create a file is not necessarily the one that most users want to open it with; the Creator Code system didn’t offer any simple way for users to modify the creator after the fact, either individually, collectively for a selection of files, or across all files of a given file type. The complexity of what users expect to do (and what kinds of data they are working with) in 2009 is vastly different than it was back in the early 80s when Apple conceptualized the rather simple Type and Creator Codes.

MIME talkin

To support new kinds of features, Apple invented a flexible new system for expressing file and creator information in a system called Uniform Type Identifiers. The idea of rich file typing wasn’t entirely unique; the BeOS began using MIME types as its mechanism for expanding upon the concept of File Type and Creator Codes during the 90s. However, MIME had its own issues.

MIME types are used by web servers and in email to express the type of file being served or attached. For example, a web server might identify a graphic as “image/jpeg” in addition to the file’s .jpg or .jpeg file type extension. MIME also allows developers to make up their own types, either by registering a specific name with the IANA (the root DNS naming authority) or making up ad hoc names, an improvement upon Apple’s registered Type and Creator Codes.

The BeOS copied a page from the web browser, which allowed users to define which helper app should be used to open a file of a given MIME type. If it encountered a specialized MIME type that it didn’t recognize (such as “text/xml”), it could try opening it with the program designated to open plain text files. This “type/subtype” system offered a two bucket approach to defining file type, allowing specialized files to be opened by more general apps if necessary.

However, MIME was originally created just as simple way to push international characters and binary attachments through the Internet’s SMTP email system (which only understands plain ASCII text). MIME only offers simplistic, rudimentary support for identifying the kind of data being transmitted. Apple wanted a much more rich and robust system for detailing more than just the basic document type of some binary data.

Data typing beyond files

Type metadata isn’t just useful for documents. It’s also used to identify data that isn’t saved in a file, such as clipboard data. When you copy and paste, the Mac OS has to keep track of the type of data you copy. An operation might start with a copy selection from a Word file with special formatting, but you might want to paste that data somewhere that only recognizes RTF (like TextEdit) or plain text (such as a search field or the name field in a Save As dialog).

The application involved has to supply as many different representations as possible to allow for different paste destinations. For example, Word may provide the pasteboard with Word-formatted text, RTF and simple plain text. The document selection copied to the clipboard might also contain graphics and text, or even embedded video. For copy and paste to work intuitively for users, the system has to accommodate pasting rich data into places where only basic data is supported; it has to know how to degrade gracefully. This requires a sophisticated data typing mechanism for identifying the different representations of copied data.

Starting in Mac OS X Panther, Apple began labeling pasteboard data (the internal clipboard used to store information between copy and paste operations) using a flexible, sophisticated tagging system that identified data in both general and specific terms. The system maintained records of how the tags fit into a hierarchy of increasingly more specific data types.

Introducing Uniform Type Identifiers

In Tiger, Apple began introducing these UTI tags as a way to identify file types as well. As with the pasteboard, a file might be tagged with the UTI of a proprietary document type, but that UTI can identify itself to the system as also conforming more generally to be rich text, as well as plain text, or most simply as a file. This UTI hierarchy of type identification allows the system to work with the data in both general and specific ways.

UTI’s added layer of sophistication in data typing is similar in some respects to Leopard’s introduction of NT-style ACLs (Access Control Lists) for use in file permissions, on top of the older Unix-style permissions. Rather than three buckets of read and write file access rights (user, group, other), ACLs allow a file to be tagged with any number of individual and very specific per-user permissions.

Similarly, with UTI, rather than two buckets of file type identification data (Type and Creator, or MIME’s “type/subtype”), there can be a wide range of increasingly specific type information connected to a file or copy selection in order to richly express how it can be used.

The UTI model

What does this extra magical layer of sophistication provide? First off, it harmonizes the pasteboard data types with file types. It’s also used in drag and drop, which is essentially a one-step copy and paste operation. It’s also used in Application Services, which is a fancy form of copy and paste where the data is transformed in between being copied and pasted, usually ending up being modified in place.

With UTI established as a uniform method of identifying a very specific data type of a file or a selection of data, the operating system can maintain a single model of how a given bit of data can be used by other apps. This also allows applications to use data tagged with a UTI they don’t recognize, but which the system knows is compatible with a type that application does know how to use.

Mac OS X can also translate existing Type/Creator Codes, MIME types, and file name extensions into its unified UTI model, bridging legacy into its new world.

UTI definitions

For example, the “public.html” UTI defines itself as conforming to “public.text,” allowing any apps that know how to use text to also access HTML formatted text, even if they never anticipated editing HTML. They could also work with a new vendor-specific UTI such as “com.editmax.htmlplus” that defined itself as conforming to “public.html.”

In turn, “public.text” conforms to both “public.data” and “public.content,” so any process that knows how to work with files or content in general terms can also work specifically with HTML files, or any new specialized forms of HTML files invented in the future.

UTI definitions also include a human readable (and localizable) description of what that file type is; identify the icon that should be used to represent that file; and outline alternative ways to express that file type. For example, the “public.html” UTI associates itself with the legacy “HTML” Type Code and a variety of file extensions that HTML files may use, such as .html, .htm, .shtml, and .shtm. It also associates itself with the MIME type of “text/html,” making UTI the uber-type of data typing.

Developers can make up their own new UTIs, defining them in relation to more general, existing UTIs, without needing to formally register anything. Vendor-specific UTIs use ‘reverse DNS’ naming just like preference files, preventing different companies from inadvertently using the same label. In the world of file extensions, there’s nothing unique about “file.doc,” as both WordPerfect and Word used the .doc extension. With UTI, Microsoft uses “com.microsoft.word.doc” to express a unique data type for its files.

As a side note, “reverse DNS” is used because DNS itself is backward. Web URLs like “www.apple.com/mac/features.html” go from most specific to least specific (in server name hierarchy), then hit a slash and begin getting more specific (in web server file hierarchy). This is like writing the number 1,234.567 as 4321.567: nutty. So “reverse DNS” is an attempt to fix a big mistake made in web URLs everywhere else that a similar naming hierarchy might be useful. It’s too late to fix the web.

Features of UTI

So, rather than just defining a file in terms of the app that created it and its general type, developers can now assign their files a UTI that identifies a very specific creator and type, and then inform the system of how that specific new UTI label relates with other more general file types that other apps (and system features) already know how to interact with. Developers can also still indicate that their unique UTI-tagged files should open with their “creator” app, a feature the end user can override via a Finder preference.

In addition to using UTI to manage what app to use when opening a file in the Finder (via Launch Services) and in determining how to perform copy and paste, drag and drop, and Application Services (via Pasteboard Manager), Mac OS X also uses UTIs within Spotlight importers, Automator Actions, and Quick Look previews, as well as in Navigation Services to narrow down the relevant files presented in open and save dialogs.

For Launch Services, Apple tells developers to define UTIs for the documents their applications create, and include these within their application. A vendor-specific UTI works like an old fashioned Type and Creator, although developers don’t have to register their definitions with Apple in advance. So rather than Adobe registering the “8BIM” creator and “8BPS” type for its Photoshop files, the UTI “com.adobe.photoshop-​image” expressively and uniquely identifies these files as entities that open with Photoshop.

Other applications can also open Photoshop documents. Conceptually, other apps could even create versions of Photoshop documents that open by default using their own app simply by adding a new UTI that defines itself as a specialized version of the existing “com.adobe.photoshop-​image” UTI. This allows the system to do everything it already knows how to do with Photoshop files (copy and paste, index for search, use in Automator Actions, Quick Look) to new documents defined by the specialized “Photoshop+” UTI. Type/Creator Codes can’t do that.

The Pasteboard’s use of UTI was introduced above. It shouldn’t be surprising that iPhone 3.0 also uses UTI in its new copy and paste support. If you were wondering why Apple “took so long” to bring that feature to the iPhone, it’s because the platform opted for a long term, robust solution rather than a quick and dirty kluge impacted by security issues.

For Spotlight searching, Apple instructs developers to provide UTI definitions for the types of files their importer plugin can index. The system then uses the most specific and specialized importer available to index files matching that UTI.

For Automator Actions, developers specify the UTIs their Action knows how to input data from and what UTIs the Action will spit out. Automator Actions are essentially a modular string of Services that are compiled together to copy data from one file or selection, transform it, and spit out a result.

For Quick Look, plugins specify UTIs for the files they can view. Again, this allows the system to select the most specialized plugin to use in displaying a given file type. In other words, a developer could create a specific plugin for viewing a fancy text UTI (such as XML) with more features (such as color-coded markup tags) than Apple’s own basic text Quick Look plugin offers. Quick Look is also an application of UTIs that allows the system itself to open a file for quick viewing without affecting the user’s desired default launching app.

The fix for Creator Code junkies

UTIs provide a standardized way for defining data anywhere in the system, one that transcends the Type/Creator Code’s limited concept of a single app that creates given file types. Developers who complain that Snow Leopard doesn’t support Creator Codes need to brush up on UTI, which has been in place for several years now. It offers all the benefits of Creator Codes while enabling lots of other modern new features.

Users who miss being able to automatically open a file using the app that originally created it can pester their app’s developer to get on the ball with UTI. Any application that has been updated since 2005′s Tiger, but which does not yet support UTI, has opted not to support an important feature of the Mac platform.

Everyone else, including many of us who didn’t ever understand why the system launched files using a specific app rather than the one we had defined for that given file type, can continue using the Finder’s Open With menu, drag and drop app launching, or set a permanent per-item default “creator” app for opening a selection of documents by using the Get Info panel.

Sorry, I think you’re just plain wrong on this one. Snow Leopard removed functionality on this one.

Without Creator Codes, there’s no simple way of setting which files get opened by which editors, something that can be quite important.

You keep a blog. You edit html. If you created a set of HTML files in Espresso or Coda or TextMate, in Leopard THOSE HTML files would open by default in the app which CREATED them, which makes sense as those would be HTML files you would be editing.

While most other HTML files (such as documentation or bookmarks) would open in Safari or Firefox or your preferred browser as those are intended to be read and not edited.

Now things don’t work that way.

[If Espresso or Coda or TextMate create a UTI that labels their HTML files as unique to them, the Finder will launch those apps when you double click on their files. The files will remain "regular" HTML. The fact that developers haven't supported UTI in that way says more about the developer and what they want than any problem with Snow Leopard.

On the other hand, if you create HTML using Coda and send me the file, I may want to open it Safari rather than the editor you use. I don't want a Creator code on it trying to open Coda, I want the option to open all HTML using my desired app. UTI solves that as well, which Creator Codes don't. - Dan]

WebManWalking

As a developer since the Single Finder, I really love your articles relating old Mac technology to OS X. This article prompted me to finally preorder your book.

I would certainly like to see an article like this one on the resource fork. I miss document resources overriding app resources overriding system resources and the level of customization that allowed. I miss ResEdit. I once wrote a computer aided instruction lesson playback app that used only a page and a half of Pascal, the Dialog Manager and a custom resource (2 if you wanted to jump between lesson files). Man, the resource fork was amazingly easy to program.

It would be great to find out what I’ve been missing, if anything, in OS X that makes OS X superior in that regard. I know about the 2-forks-to-2-files hack to keep resource forks working from seeing all of those dot-prefixed filenames copied to PC formatted disks, but what about more OS X-y structures such as files that are actually folders if you right click on them? Are packages really that much better than multiple forks? I’d love to read your exposition as to why you think they are.

As for godofbiscuits’ lament of wanting some files to open with one app and other files of the same type with a different app, your reply didn’t really answer his need. Sometimes you just can’t force the app developer to support UTI. We don’t have as big a voice in the software community as you do, Dan.

Now, if there was some OS X-y way to give specific files the UTIs that the USER wants them to be, and for those file-level UTIs to override application and system UTIs (similar to how the resource fork used to do), and if it were possible to do that by selecting some files and context-menuing a system service to do that, well then, now we’re talking.

godofbiscuits

I don’t want a Creator code on it trying to open Coda, I want the option to open all HTML using my desired app. UTI solves that as well, which Creator Codes don’t.

Actually, if you’ve set all documents of a certain type to open with a certain app, they will. This has been true throughout the life of OS X.

godofbiscuits

And if Coda slapped a Coda-specific UTI on all of its documents and you had Coda on your system, wouldn’t they open in Coda? If not, why would they be there? If so, how are they different to creator codes?

http://www.transchristians.org Ephilei

Fascinating. I just wish I understood the whole article.

http://eliteconceptual.com JasonBee

I am inclined to lean towards the position of the Mr. Dilger.

Although I’ve often preferred the “idea” of the creator and type codes, in actuality I find myself tending to prefer the file extension owner’s default app in reality.

I work with everything from video to code (AVI, MOV, M4V, MPEG, etc…to HTM/L, VBS, TXT, CMD, BAT, INI, HTA, etc…) and in many cases I switch between platforms (UNIX, Win32, MacOS, Linux) to accomplish many tasks. It’s only when I run into the legacy embedded creator and type codes that consistently end up inconsistent that I go a little crazy. I may edit that HTML file in BBedit, but I want all HTML files to open in TextMate first!

I realize personal work styles will conflict, but the idea of having a single owner for a given file type is a major improvement for me. I don’t want your HTML file coming to me as “blank” and unknown if I don’t own CODA, although I suspect in my own ignorance that that particular situation won’t be an issue on 10.5. I do know that in years past I used to keep creator and type applets on my desktop to specifically strip incoming file or downloaded attachments of their original associations.

Nice article BTW. And also nice feedback everyone. I find it hard to find such quality discussions elsewhere.

godofbiscuits

Again, you’ve always been able to set a single owner for a given file type. (e.g., Get Info on a PDF file and choose what app you to open it. Check the box if you want ALL PDFs to be opened by that app).

Snow Leopard removed the ability to distinguish creators of the same file type, with no way to make it stick for any given individual file.

In other words, Snow Leopard removed functionality.

I’m a developer. I’ve been a developer for a long long time. I know what UTIs are. I think they’re a great idea. They could have been *additional* metadata for files–and in fact, *have been*, as has been pointed out by the author.

The rest of us have been complaining that Apple removed functionality that was valuable.

Just like they did when they removed FSRef functionality when they went to URL-based file access a few versions ago–and they put the functionality back later, albeit in another form.

That’s what’s been taken away in Snow Leopard.

darwiniandude

One thing I can’t work out Daniel is why in Snow Leopard file copying seems to have gone backward. On Leopard and earlier, since forever, I can drag a CD on the desktop and hold option. A plus appears, when I release it creates a folder called CDNAME. Whilst it’s copying, I can rename that folder, then drag and drop with spring loaded folders anywhere in the file system… while it’s copying. I’ve always loved and used this feature. Start the long copy first, worry about the folder name and storage place once the transfer has started. But in Snow Leopard, they’ve taken this from me and it just makes a very Windows like error instead. I preferred the ‘magic’… I hope they bring it back. :( Any ideas on this one?

http://www.jphotog.com leicaman

I just used Applescript the other day to read the UTI code and determine whether a files should open in Quicktime X or Quicktime 7. This UTI thing is probably more of a problem because people (including many developers who should know better) have simply not learned about them. Sal Soghoian and Bill Cheeseman put a lot of info about UTI and Applescript in their recently released Applescript 1-2-3 book. Worth a read – several times.

gopyvision

godofbiscuits: “Snow Leopard removed the ability to distinguish creators of the same file type, with no way to make it stick for any given individual file.”

No it didn’t. It’s in the Get Info panel. If I Get Info on one .png and change its application to Safari, that picture opens in Safari from then on and all other .png files open in the default application, marked default in the Get Info popup menu of possibilities. Unless I press the Change All button.

What confuses me about this whole topic is that, as a user, I’ve been using the Get Info panel /forever/ (in OS X) to change application owner, thanking Avi and Bertrand that there was /finally/ a way to do this in the Finder. (And seriously, who the hell would think of “BOBO” for ClarisWorks documents?) What also confuses me is that while Type/Creator codes were /certainly/ a lot nicer than file extensions, they had their own problems. For example, I’d open a document with a program I had open at the time for a quick change instead of newly opening its owner. Save that document, all of a sudden it has turned into being owned by the happened-to-be-open app instead of the 99%-of-the-time app.

UTIs seem to offer more flexibility, and change has to happen or else we end up with essentially the same creaky old OS for ever and ever (I’m looking at Classic, here). It’s far better/easier to have one complex but more flexible system, and craft a simple UI for it than it is to try and make a once-simple system flexible enough for explosively-networked environment we live in now or even to use two or three /different/ systems (UTIs, Type/Creator, file extension).

Disclaimer: I hope my memory of Classic has stood up through time, but I make no guarantees. I knew it pretty intimately as a user at the time, but I was also a teenager who duly experimented.

JohnWatkins

Just a suggestion. It would be nice if you used higher quality images for your diagrams. They are often difficult to read (not a huge issue for this article, but it has been a major PITA for some of your previous ones.) Perhaps existing images could link to higher res ones? Or perhaps use the slightly higher quality images that you use on AI? Thanks.
Interesting article.

dotmatrix

Perhaps you could expand on how the current Uniform Type Indicator implementation could allow me, for instance, to have most PDFs open in (prettier, faster) Preview but have others, which contain features Preview doesn’t support (such as JBIG2 image compression), open in Adobe Reader. This works perfectly in Leopard and earlier, and now fails without warning in Snow Leopard. Another example is Nisus Writer files, which are RTF but include many more features than TextEdit. I love TextEdit, but it will delete the extra stuff from the Nisus file, ruining the format, if you accidentally save it.

You can set individual files to “Open with…” selected applications manually using the Get Info window, but this is not practical for thousands of files acquired over the years. Also, this works by writing into the file’s resource fork, creating it if necessary, which is certainly no more robust in foreign file systems than the creator code and somewhat at odds with Apple’s recommendation against using resource forks, plus it uses disc space where the creator code doesn’t (all HFS directory entries have slots reserved for type and creator).

Correct me if I’m wrong here, but I see no way to attach a customized UTI to a file, which is required for them to duplicate the function of a creator code. UTIs appear in an application’s Info.plist file, in system headers, attached to pasteboard data, and AFAICT nowhere else. I certainly agree that an improvement on file type codes and filename extensions is long overdue — I mean, how overloaded was the TEXT filetype? — and the human-readable, no-registration-required UTI is probably worth the disk space. But it can’t replace the independent creator code until a UTI can be attached to an individual file. And Apple should provide some automatic tool to accomplish this for the billions of preexisting files with creator codes, or just go on using them.

http://www.roughlydrafted.com danieleran

@dotmatrix

Creator Codes basically make a subtype of a type that’s no different from the type, but simply owned by specific app. The use cases you describe are examples of why somebody might want a specific subset of RTF or PDF or whatever to open with a specific app.

The problem is, why? Why not create a speecific file type? Nisus can create com.nisus.richtext, and save RTF that it is the default opener for, while allowing the file to open on other systems.

Of course, some people create say, HTML with BBEdit, and don’t want to create bbedit-html, they just want to create html. The possible solutions would include tagging the file with a resource fork containing “open with” data via Get Info, or simply making BBEdit the default app for users who are editors, and a browser as the default app for users that are reviewers.

The underlying issue isn’t that Snow Leopard stopped using Creator Codes to determine how to launch a file’s app, but that it deprecated Creator Codes a very long time ago.

Why? if you have a system that relies upon HFS+ metadata, you can’t interoperate with other platforms very well, you can’t adopt other file systems (remember ZFS) very well, and you can’t transition your platform to entirely new and clean things like the iPhone (and that tablet, I’m betting).

So yes, Apple did break some eggs, and some users are impacted. But (even more?) users were impacted before by the opaque, mysterious, and out of reach implementation of Creator Codes, which had lost their magic as the world expanded and Mac users began doing more complex things.

So no, UTI isn’t a drop in replacement for Creators that does exactly the same thing, because doing exactly the same thing is not the desired behavior (from Apple’s perspective). UTI offers a broad solution to a variety of problems, and allows a form of Type/Creator functionality (although certainly not identical).

The bottom line appears to be, if you want documents bound to a specific app, you either do it by file type (assigning a default app for “all apps of this type”) or by creating a new file type (a specific UTI “exported” by your app), or you can fall back to adding a resource fork to tell the Finder which app you prefer to open it with (via the Finder’s “open with”).

But Apple appears to see no value in saying, “there are a few general document types, and each file of a given type can be owned by an app.” Naturally, some people don’t like that, as is the case with any decision.

One could argue that Apple should offer the option in the Finder to “respect Creator Code when evaluating how to launch an app for a given file.” But if we’re talking about ways to fix the Finder, I have several hundred ideas I’d prioritize ahead of that, and it appears Apple has no motivation to do much with the existing Finder anyway.

Perhaps 10.7, or perhaps someday when it results in a return on investment.

jdb

Daniel, your follow up is clearer than your original post.

To summarize: There is no replacement in Snow Leopard for the ability for a program to set which application will open a particular file. There are mechanisms to do that in the Finder but Snow Leopard does not provide a for it in a public API.

This in my opinion is a good thing. I’m in the camp that finds creator codes where far more annoying than useful. It has never been clear to me why the common case of opening a file in a viewer application should be subservient to the much rarer case of editing the file in a heavy-weight authoring application. Why do I have to use the Open With control (right) click for the common case of viewing content instead of requiring the rare case to choose an alternate application for authoring.

This writing stuff is hard :P. My summary is just as confusing as everything else. What I should have said was:

To summarize: There is no replacement in Snow Leopard for the ability of a program to set itself as the application that will open a particular file when that file is of a common type such as HTML or JPEG and not a custom format of the application. There are mechanisms to set the default application on a per file basis in the Finder but Snow Leopard does not provide a for it in a public API that can be used by an application when a new file is saved.

http://www.garner.cx garnercx

Dan, just a quick thing, your graphic (i assume you made it dan!) says “The quick brown fox jumped over the lazy dog”. It should be “The quick brown fox *jumps* over the lazy dog”. With the second version you use every letter of the alphabet once. With the first version you miss the ‘s’ and add and extra ‘e’ and a ‘d’.

Just sayin’

:)

walter

@jdb: There is a mechanism, and it has been explained repeatedly. All the application has to do is declare a new type to be an extension of the common format, and register itself as the handler for that custom type. Any files it creates can list themselves as the specialized type. If the document is an HTML document, any program can declare a type like com.company.program.html to extend public.html, and then handle that specialized type.

This exactly duplicates the creator code functionality.

http://www.jphotog.com leicaman

@jbd: “To summarize: There is no replacement in Snow Leopard for the ability of a program to set itself as the application that will open a particular file when that file is of a common type such as HTML or JPEG and not a custom format of the application.”

To summarize: “I didn’t read the article carefully.”

jabah

Something to consider when suggesting that users should bug developers to add UTIs to their app is that UTIs were not well supported on Tiger and caused many problems when you added them (for instance, stealing filetype associations from other applications which used Creator Codes instead of UTIs, IIRC). So if your app supports filetypes that other apps also support, you have to drop support for Tiger in order to add UTIs. Someone can correct me if I’m wrong about this, but to this day I only have UTIs defined in my app for ‘custom’ filetypes, while shared filetypes retain their old-style info.plist entries, due to the nightmare of confusion that ensured when I tried to add UTIs.

JohnWatkins

It pleases me to see careful thought put into innovation for usability.

It seems like apple is the only *company* that puts in the effort to rethink things like this. Some companies have *people* or *departments* that work on these things, but in the end, the companies tend to worship the status quo and are typically afraid to break any eggs, even as they claim to want to make omelets. Apple is unique in that they consistently quest for innovative approaches to genuinely enhance usability or make something better. Gotta love it (even if it seems temporarily annoying.)

jdb

@leicaman

The article implies that you can use a standard extension like .jpg and have an application override the default application for .jpg when a file is saved. This simply isn’t true in Snow Leopard. Dan acknowledges that in his follow up.

“So no, UTI isn’t a drop in replacement for Creators that does exactly the same thing, because doing exactly the same thing is not the desired behavior (from Apple’s perspective).”

I agree. The old behavior is confusing and inconsistent to most users. Some few old-time Mac OS users are going to have to find a simple change to their work flow such as drag and drop of files on an open application or using a control-click Open With to open files in a different application from the default. This is better than the existing system where you never really know which application is going to open for a particular file without using Open With.

Any application that wants to retain the old behavior is going to have to define its own extension. Instead of file.html it will be file.bbedit-html. When done editing/authoring, export the file to use the standard extension.

jdb

@walter

Most old time Mac OS users who use and like the file creator feature of the previous versions of Mac OS/OS X aren’t going to be happy with needing a new file name extension for existing file types in order to do what they used to do with creator codes.

While there is a solution, in order to make it work in the current version of Snow Leopard, the developer has to define a new file extension. That means that file.html is now file.bbedit-html. Read the article from Ars Technica. It explains this in detail.

From http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars:
“Given a file on disk, Mac OS X provides a way to get a UTI representation of that file’s type. This may lead you to believe that, like the classic Mac OS type codes, there is a storage location somewhere in the file system for the UTI of each file. This is not the case. Instead, Mac OS X derives the UTI from other information, primarily—and tragically—from the file name extension.”

I read the Ars Technica article, and extend my apologies for misinterpreting the facts. I did not know that the UTI type was determined from the file extension. Instead, I thought that this could be set.

It seems to me the best way to do this is what Siracusa mentions: define an extended attribute to store the UTI.

Extensions are useful, which is something old-time Mac OS guys don’t always understand: when you aren’t using a graphical interface to present a pretty icon describing the file type, the extension is a quick indicator. However, there should be a way to declare a file as a special instance of a more generic type that does not depend on extensions.

http://all.net/ hylas

Daniel wrote:

“UTIs provide a standardized way for defining data anywhere in the system, one that transcends the Type/Creator Code’s limited concept of a single app that creates given file types.”

Which clarifies the subject of distinguishing between file formats / types.

I thought (this part of) walter’s nutshell explained it well enough …

“All the application has to do is declare a new type to be an extension of the common format, and register itself as the handler for that custom type. Any files it creates can list themselves as the specialized type. If the document is an HTML document, any program can declare a type like com.company.program.html to extend public.html, and then handle that specialized type.”

But then walter later clarifies:

“However, there should be a way to declare a file as a special instance of a more generic type that does not depend on extensions.”

You seem to attribute the use of reverse DNS in things like UTI to a desire to correct the backwardness of forward DNS. But there is a more utilitarian explanation for why Apple may have selected reverse DNS order, especially in the context of preference files: sorting. When preferences files are sorted, they are naturally ordered by company, so all of the Apple application preferences are contiguous in a listing of preference directories. Using reverse DNS for other designations, such as UTI, is a natural way to preserve consistency.

While this generally makes sense, it is not without its drawbacks. For example, I have an application called LaTeX-iT. I do not know the reverse DNS name for this application. Instead, I have to go to my Preferences directory and obtain a listing for files matching *[Ll]a[Tt]e[Xx]* just to find the preference file. If the application name were first, I could just scroll down the total list to the “L” section and would have a pretty easy time finding things.

For the record: the name is fr.club.ktd.LaTeXiT.

NormM

I don’t think UTI’s are a good solution for content developers that want JPEG’s they create to open in a particular app.

On the other hand, AppleScript provides a way to set “default application” in the “System Events” dictionary, so there’s no missing programmatic capability. Content developers can just use an AppleScript system service that saves the file with the current application as default.