Month: October 2004

File Calumnies

Now that I’m newly thinking about helping out with another project in Cocoa, it’s getting me thinking about some issues I’ve had with Cocoa.

Let’s start with files.

Here’s a demonstration for you. Open TextEdit and save a file to the desktop. Go to the desktop and move the file somewhere else. Then go back to TextEdit, modify the file, and save it again.

Presto! New file on the desktop.

Do the same thing in BBEdit. No new file appears on the desktop. Instead, the changes are made to the moved file.

Now, some of you are saying, “Ah ha, bug in TextEdit!” Others of you are saying, “Ah, ha, weird behavior in BBEdit!”

This schism is described in detail in the macosx-dev mailing list thread “Paths, FSRef, Alias, Resource Fork, and the Big Schism”.

As an old Mac user, I think the BBEdit behavior is correct – just because you’ve moved a file doesn’t mean it’s in any way different. The most effective argument to the contrary is that many computer users aren’t used to this behavior, because of experience with Windows and Unix-like OSes.

Another argument in the thread is that, in certain circumstances, this isn’t the behavior you want. For developer projects, for instance, you often want the IDE to refer to projects by paths relative to the project or a particular location. Moving a file doesn’t mean changing the path, it means removing that file from consideration in the project.

I had already gone down this route with my now-abandoned Toolbox-based MacTADS. Writing your own framework does give you the freedom to, say, come up with your own, appropriate file classes.

But I do think that, apart from those special cases, I as a user would rather have the BBEdit behavior. So it distresses me (a) that Cocoa does not have a real file class, and (b) that I so often see NSString substituting for a file reference.

My Kingdom for a Scrollbar!

So: I give up.

I suppose I have to tell you what I give up, eh? But it’s embarrassing to me both coming and going, so bear with me.

I’ve mentioned a side project here before. It’s called MacTADS. TADS is a specialized language for writing text adventure games, a.k.a. interactive fiction. There is an ancient compiler/debugger/runtime suite for the Macintosh for making such games. About five years ago, I took over maintenance of it. After making some small changes to it for a while, I decided to rewrite it completely, but with a twist: since the games themselves tended to be amazingly backward compatible, I promised that so would the developer suite. I would fully support from System 7 to the yet-to-be-released Mac OS X.

Even then, it wasn’t the smartest idea, but at least it wasn’t completely insane. The users of such a specialized tool are few and far between. If, during its life, MacTADS has fifty regular users, I will be surprised and gratified. And two of the people at that point who were most likely to be users of the product hadn’t even upgraded to Mac OS 8 yet. I was doing it for them!

Well, the years went by. My efforts had morphed into a C++-based framework called “Isthmus,” since it was a bridge to the past. Steve Jobs declared Mac OS 9 dead. Most people I knew started using the ported Unix command-line tools to compile TADS games. I lost touch with one of my 7ers, and the other gritted his teeth and started using OS X on a new machine. I continued on, mostly because I’d made a promise.

For the last six months or so I’ve been working on preliminary Appearance manager 1.0 support for OS 8, which turned out to be surprisingly difficult. If I could’ve achieved it quickly, if I could’ve gotten a product out by the end of the year, I would’ve kept going.

The straw that broke the camel’s back was Appearance list controls. I’d mostly gotten them working the way I wanted, after quite a few problems and nasty workarounds, but found out that if I didn’t put enough content in them before they were displayed, they didn’t show scrollbars correctly. I would either have to fill them with bogus content, or spend three days, if it was even possible, tracking down the exact technical cause of this problem for a more targeted workaround. Six months of such investigations and workarounds!

And I hadn’t even started on Carbon.

So: I’m giving up.

Which way is this embarrassing? That I’ve been working on System 7/OS 8 support for an app in 2004, for a nonexistent audience? Or, for those people who value promises, that I can’t even keep one damn promise?

You, my readers, can decide.

What to do next? Well, there’s already an OS X-only, GUI-based compiler application out there, called TADS Workbench for Macintosh, written by my friend Uli Kusterer. It doesn’t support OS 9, and it doesn’t support earlier versions of the TADS language, which were some of the things that MacTADS was going to do, but it works, which gives him a major advantage over me! I am currently in touch with him about collaborating on new features for that application, especially debugger support.

And who knows? Maybe I’ll just take a break for a while.