Idle Time

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.

Reflecting on this week's release of Mercedes-Benz Mixed Tape #28, I momentarily couldn't remember how I found out about the Mixed Tape. Then I remembered: It was featured on Jay is Games over a year ago.

A car company gives away free music, and I found out about it from a game review site.

I love the internet.

Every once in awhile, Jeopardy! does a special series of episodes called Celebrity Jeopardy!, where the contestants are celebrities playing for charity. Most of them are laughably bad, and I mean that literally: I (and the studio audience, and the contestants themselves) actually laugh at their poor responses. The celebrities are mainly there to provide entertainment, and to bring attention to their charities and their own projects and to Jeopardy! itself; playing a few rounds of Jeopardy! is a formality.

The problem is simple: Regular Jeopardy! games are populated by contestants who pass one or more screening tests that verify that they meet some minimum standard of knowledge, comprehension of English, and ability to operate the buzzer. Celebrity Jeopardy!, on the other hand, is populated by celebrities. They have no qualifications other than being famous and being willing to be on the show to benefit a charity.

This year, they're doing a variation of Celebrity Jeopardy! called the “Jeopardy! Million-Dollar Celebrity Invitational”, where they have one Celebrity Jeopardy! episode every month for nine months, followed by a three-day semifinal and two-day final in the tenth month. The other episodes in each month are at least mostly regular episodes, perhaps with a Tournament of Champions, Kids' Tournament, or College Championship at some point.

Tonight was the first episode in this celebrity tournament. The contestants were Andy Richter (for St. Jude Children's Research Hospital), Dana Delany (for the Scleroderma Research Foundation), and Wolf Blitzer (for the American Cancer Society). Richter's performance tonight inspired this post.

Andy Richter decimated his opponents. Dana Delany did pretty averagely, entering Final Jeopardy! with $2800; Wolf Blitzer ended up well negative (they gave him $1000 with which to play in Final anyway, since this was a charity event). Richter got most of the answers, and he almost always gave right questions. He even ran a category.

This tournament, every celebrity's charity is guaranteed a minimum $25,000 donation, and each winning celebrity's charity is guaranteed a minimum $50,000.

Andy Richter won $68,000.

It makes me think that most celebrity contestants just show up, figuring that it's $25k their charity wouldn't have otherwise, and all they have to do is stand there for an hour or so and throw out an occasional right answer—something regular contestants can't do, because they have to earn their spot behind a podium. And it makes me think that Andy Richter didn't do this: He took this tournament seriously, and put in the exact same study and buzzer training that any regular contestant would have done.

I could be wrong. Maybe the other two contestants just got screwed on the buzzer (although that wouldn't explain Wolf Blitzer's score). But if I'm right, Richter's charity should be really happy with the work he put into it.

I have one idea for how Sony (the company that runs Jeopardy! in the US nowadays) could improve things. Tell every celebrity who agrees to play that they will have to take the same screening test as a regular contestant would have to. If they fail, no problem: They still get to play. But if they pass, Sony doubles its minimum donation guarantees for their charity. That may be enough of an incentive for celebrities to take it as seriously as Richter seems to have done, and bring a real game to the Jeopardy! set like he did.

You might object that I shouldn't complain about these celebrities who are playing for charity; after all, isn't it great that the charities get all these thousands of dollars for free? True, but the celebrities can win even more money for them, and I think Richter demonstrated that it's much more entertaining when they do.

On a related note: I wish Jeopardy! episodes were available online.

UPDATE 2009-09-19: YouTube to the rescue: Part 1, part 2. Thanks to Ian Baird for linking to one of them.

As you may be aware, I've used iShowU in the past to record screencasts. Yesterday, after iTunes 9 came out, I went to record a screencast of one of its features, but was stymied because iShowU, even as of 1.74 (its current version), stopped working in Snow Leopard.

So, on Twitter, I solicited recommendations for a new screen-recording tool.

iShowU doesn't work under Snow Leopard. What's a good replacement?

(Not ScreenFlow, not QTX)

After some of the nominations came in, I wrote a list of features I require:

My requirements:

1. A rectangle, not necessarily whole screen
2. Animation codec
3. Size presets
4. Good UI

…

QuickTime X fails at the first three points: It can only record the whole screen, and only in H.264. Its UI is “good” through extreme simplicity, which it achieves through (presumably deliberate) lack of features.

ScreenFlow's exclusion is special. I've always been put off by a passage from its marketing copy:

ScreenFlow has advanced algorithms that only encode areas of change on your screen.

OK, so either they're unnecessarily sucking up my CPU with “advanced algorithms”, or they're using a Quartz screen-refresh callback (like they should be doing) and calling it “advanced algorithms”. Neither possibility impresses me.

Here are the other contenders, in order by nomination.

Snapz Pro X, nominated by Steve Streza, fails point four, as I harshly told him in reply. (Sorry!) As I said in my reply, it's designed for taking static pictures; every time I've used it, I've found that that UI doesn't work well for creating movies. I don't remember whether it satisfies points two and three or not.

Camtasia, nominated by Chris McQueen, has been around on Windows for a long time, but recently joined the Mac market as well. It looks nice, but it's way too pro-caliber for me. On the other hand, if I didn't already have Final Cut Express, I'd probably take a harder look at it for its editing tools.

(Say, I wonder if my old version of Final Cut Express (3.5) works in Snow Leopard. Hrm.)

This is the point in the timeline where I published my list of requirements.

I dismissed Screen Mimic, nominated by Rob Rix, for three reasons: First, I'd already found my winner, which strangely received no nominations. Second:

Flash-based screen recording for OS X

It's not as bad as that makes it sound (well, not as far as I can tell without downloading the demo, anyway). What they mean by “Flash-based” appears to be that it can export the recording as Flash video as well as QuickTime. It's probably a nice enough app, but the idea that it's designed around Flash put me off.

The third reason was that there are no screenshots. I know these are screen-recording apps and it's good to eat your own dog food, but static pictures are good, too. I can load and look at a full-res static picture much more quickly than I can load up even a half-res video. The faster I get to like your app, the more likely you are to make a sale; conversely, throw delays in front of me, and I'm likely to give up.

The final nomination, from Uli Kusterer, was Screenflick. It looks nice enough, but fails point 3 (presets).

The winner, which I found independently, is Screenium. It's simple, it satisfies all of my requirements, it works in Snow Leopard, the trial limitation is pretty good (full quality, but no more than 30 seconds per recording), and the price is only $29. It even has a button to set the target rectangle to that of a specific window, which was perfect for the video I had in mind at the time. Plus, it has QuickTime export built-in, so I no longer have to use QTAmateur for that.

Here's the video, which I recorded using Screenium's trial mode. (If you don't want Vimeo's scaled-down version, hit the download link in the lower-right for the full-res QuickTime movie I uploaded. That'll be up for about a week.)

Thanks again to everyone who replied for all of their nominations.

The new version of TimeMachineGrowler includes compatibility with Snow Leopard and a few fixes. Plus, I've created a Google group for it, so you can get news of any further updates there.

Starting with Xcode 3.2, the Xcode installer package no longer includes a local copy of any developer documentation. Instead, you have to either go to the website (which is what the redesigned Documentation Viewer window does) or download the documentation within Xcode.

Both solutions have their own problems. Reading the docs on the website can be frustrating if you're streaming or downloading something in the background. And downloading within Xcode is dubious if your internet connection is not super-fast or is flaky, because Xcode cannot resume downloads.

There is a third solution.

1. In Xcode's Preferences, click on an info button at the right edge of the list of docsets, or right-click on the docset and choose “Get Info”.
2. Select the row labeled “Feed URL”, and copy it.
3. In a text editor or text field, paste the text, then edit it (it's the whole row, not just the value) down to the URL alone. There's a period (full stop) at the end of the text; it's not part of the URL, so make sure you delete that.
4. Open the URL in a feed reader.
5. On the most recent entry, copy the URL for the enclosure.
6. Paste it into your download manager or browser Downloads window.

Assuming your download manager or browser supports resuming downloads, you now have a way to pause the download for any reason that may arise, and resume it from that point.

Of course, then you have to install what you downloaded. You're probably not used to seeing xar files (although you've seen more than you think—flat packages are based on them), so you may not know what to do with them.

1. Pop open a terminal. cd over to where you downloaded the xar archive.
2. pushd /Developer/Documentation/DocSets
3. sudo xar -xf ~+1/filename.xar
4. Once that finishes, delete (or back up) the xar file.

Xcode's Documentation Viewer window (or your browser) should suddenly be much quicker.