« UTI's don't work if you don't set them correctly [UPDATES] | Main | This is going to cause a wormhole »

So I posted my article about the Apple file handling debacle in Snow, (and just in case i wasn't clear enough, i was wrong about a few things in that, and Apple really is screwing the pooch here), and lo, the 'real' programmers come down from the mountain, and tell me how using UTIs to tell the OS what fucking application to open the fucking file is some kind of heresy, and will break UTIs, break the OS, break physics, fuck, I don't know, it's all bullshit.

The latest entry is from Peter Hosey, How not to use UTIs. It's yet another entry in "why developers have a hard time figuring out why people hate their software, because they are too wrapped up into ideological purity to get shit done." Peter's problems, and they are many, at least within his article, exactly represent the kind of narrow-minded worship of ideological purity that the idiots at Apple who think that all you need are filename extensions have that caused this fucking problem in the first place.

Now, into the stupid:

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.

Oh fucking spare me. First of all, the UTI entries in an info.plist file most certainly DO identify the 'creator' of the UTI, aka the part of the UTI that is the bundle identifier. In Coda's case, the bundle identifier is com.panic.coda. Why is that better than a creator code? Well, for one, because you have more space. For example, both Acrobat 7 and Acrobat 8 use the same creator code: CARO. So does Acrobat 9 for that matter. If adobe wants to differentiate in the creator code, it has to create and register a new one. That's where you run into real problems, because getting useful information out of 4 characters is a bit hard, especially under a system that's been in use for twenty fucking years. At some point, you run out of space. However, using the bundle identifier, this is fucking trivial, because you can do something like com.adobe.acrobat7 or what have you. Bundle Identifier win.

When we look at the exported type UTI section of Coda's info.plist file, what do we see? They all start with the bundle identifier, aka A BETTER VERSION OF A FUCKING 4-CHARACTER CREATOR CODE. Guess what Peter? That creator code information? IT'S ALREADY IN THERE. Yeesh.

So then Peter goes off about my CSS example:

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?

They both are. Look, i know that the idea of multiple right answers is hard for an idealogue, but follow the fuck along for a minute. What both of those UTIs, (at least in my view, which is anything but ideologically pure) are saying is "this is a file of type CSS that should be opened by <application>. That, by the way is what the combination of a file type and a creator code did prior to Mac OS X 10.6. It said "this is a file of type foo, and it should be opened by application bar. A perfect example of this was a text file. Text files all had the same type: TEXT. But depending on what application created it, the creator code would be different. ttxt, R*ch, whatever. The fact that a file had a specific creator code did not, in any way, shape, or form, prevent another file that could handle that file type from correctly opening it. All it really meant is that when you double-clicked the file, the application that was represented by the creator code would open the file.

There is nothing about com.macrabbit.cssedit.css vs. com.panic.coda.css that creates any more problems than TEXT/ttxt vs TEXT/R*ch did, unless you're going to tell me that Mac OS 9 was far more sophisticated and better at this than Mac OS X is.

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.

Okay, let me just say something. None of this shit will prevent an application from opening, or trying to open a file, unless the programmer is really short-sited and says "unless a file perfectly matches this list of conditions, don't even try to open it." While that does happen, it's pretty fucking stupid. If i want to try to open PDFs in Word, fuckit, lemme try. The worst that can happen is that it will fail, and Word might crash. Big deal. You cannot prevent stupidity, so stop trying. Just fail gracefully when it happens.

Onward and upward. I'm going to skip some of the more blindly ideological shit, it's just kind of dumb. Some random hits:

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?

Because Apple's fucking stupid, and not letting applications explicitly set this, and so we have the problem in Snow.

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.

So then how the fuck do Cocoa applications deal with this? Well, usually the filename extension. that's right. you want to completely bugfuck a Cocoa application's ability to open a file from a double-click in the Finder, change the right part of the fucking filename. All hail the glory of Unix purity. Hail Cthulu.

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.

No shit sherlock, and that's what i'm saying to extend UTIs to do as well, since they're 90% of the way there already.

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.

Bundle Idendifiers, which are, rather a lot, part of the fucking UTI. Jesus, this is not fucking hard to figure out.

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.

I've got a very short AppleScript that will show you how stupid an idea it is to absolutely rely on filename extensions for this. Fuck, i don't even need that. Here, let's play "file names are not reliable metadata" using the Cocoa way:

1. Here's a file: test.css. What kind of file is it? Well, we hope it's a CSS file. We don't know, but since all we are allowed to use is the filename extension, css file or fucking jpeg, it's opening in whatever the OS has decided should open .css files.


2. Oops, Bob the technologically illiterate user renamed it test.jpg. The file itself hasn't changed, but we don't care, because we are doing things in an ideologically pure fashion. The filename extension is now .jpg, it is now and forever a jpeg file, and will open in some form of image handling application. Won't that be fucking fun


3. Did I say forever? Oops, i meant until bob decides it's obviously the fucking extension that is makeing his Macbook go insane, and just lops the fucker off. Now what kind of file is it? WE DON'T KNOW, because according to our ideologically pure way of life, only the file extension can be used to decide what application opens anything.

All hail slavish ideology. Hail Cthulu.

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.

That's pretty fucking handy. Oh sure, you spend hour creating that PNG in Photoshop, but now, to open it in Photoshop again you have to:

• Open Photoshop first, THEN open the file. Fuck that double-click convenience, this is ideology pal!


• Change the default PNG handler for EVERY FILE, (assuming of course, you're using filename extensions. If you aren't, you have to, because sans anything else, the OS now has no fucking clue as to how to handle a file without an extension. I really missed DOS, didn't you?


• Use the Finder to add a resource fork to the application, which will break if Photoshop's location ever changes, because it's using a static file path. Whoo-hoo! Relive the glory of 1983!

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.

And now you know why smashing type information and creator/opener information into a single value is a bad thing.

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.

That's not going to break a fucking thing, and it's not jamming all the information into one value. As well, as a programmer or the OS, it's not your job to tell me what kind of file i want to make something. For one thing, really, there is no such thing as an HTML file. It is a text file. Period. The only difference is when the right application reads the file and interprets the data. Since you're so against 'changing' files, then regardless of what the content of the file is, if it is a plain text file, the ONLY default application should be whatever is the default for plain text.

That, by the way is the kind of asinine logic that ideological purity gets you.

You want to live in that world, where you can only use filename extensions, or the OS can never, ever progress beyond 1984 without inventing some completely different mechanism that would STILL have to fit into Launch Services and most likely be effectively indistinguishable from just sucking it up and using the information we already have today for this shit, you go right the fuck ahead, but I'm not going wait around another ten years just so you can have your ideologically pure spankfest. I have work to do, and users to support, and UTIs solve far more problems than they cause.

Comments