Just One More Thing…

So if you haven’t been reading the comments, there’s already something similar to what I want out of a file-specifying widget in the standard Open and Save dialog boxes, if you just hit Cmd-Shift-G to bring up a separate little utility dialog.

But I don’t want a separate, after-the-fact solution, sprung on the unsuspecting user like a last Columbo question. I want something integrated.

Speaking of after-the-fact, one thing about Panther that really bugs me is is the FileVault prompt to save space in your encrypted file. There’s no preference in the UI for “always do this,” nor is it part of the “Are you sure you want to log out” dialog box. Nope, it’s just thrown in there after everything else. Instead of making the hard choices of what other UI to change to incorporate this new workflow aspect, they went the easy route: easy for the developer, a pita for the user. I’m both a (picky) user and a developer who tries to do the right thing, so this sort of thing makes my head explode.

Forest for the Heterogeneous Trees

When you’re holding a hammer, everything tends to look like a nail.

Similarly, it seems, when you’re writing an app for Mac OS X, complex UI problems tend to look solvable via an outline view. Don’t do it!

Here’s iTunes:

iTunes left panel, including Library, playlist, shared music tree, and more

Most people think of the left pane of the main iTunes window as a simple list, not a tree. But as you can see, with the addition of shared music, now it at least includes a two-level tree.

Inverting the capitalization pattern, here’s Xcode, a rather longer example:

Xcode left pane, including source files, targets, Find Results, and more

Now, what problems do I have with these examples?

The first problem is the “which one of these is not like the other?” riddle. Many of these aren’t like the others, but they should be. My belief is that a single outline should consist of homogeneous hierarchies, like the file system objects in Finder windows or the songs in a playlist. This simplifies the user experience and leads to a cleaner, less cluttered UI.

The second problem derives from the first. In Xcode, for instance, to get to the Targets, you need to get below the project’s groups & files hierarchy. But that hierarchy is a variable number of rows long: every time you open or close another group, you change where you have to click to get to Targets. Same with Find Result: any group you open or close above it shifts its position, making it more cumbersome to get to.

iTunes, with shared music, is even worse. Where you have to click to get to your playlists depends on what other users are currently on the local network!

CodeWarrior, which has to deal with a similarly large amount of complex information as Xcode, does this in what I consider to be the right way, by separating the different trees:

CodeWarrior window

Each tree is homogeneous, so the user doesn’t have to manually navigate around unrelated UI to get to what he or she wants. For example, Targets as always easily accessible. Muscle memory can do its thing.

Now, is there no value to doing it the other way? I wouldn’t say that. Some people probably like not having to switch panes to get to all that information, and certainly the whole muscle memory/spatial Finder concept isn’t in the ascendancy right now.

But if you agree with my reasoning, then hear my plea: just because NSOutlineView is easy doesn’t mean, for your own apps, you shouldn’t take the extra time to put together appropriate UI to show complex data to the user. Look at CodeWarrior for what I consider to be some good examples of this. Just remember: keep unrelated lists and trees separate, don’t lump them together as nodes of a larger tree.

One last example. Here’s TADS Workbench for Macintosh:

Workbench for Macintosh window

This is the app I’m going to be taking over maintenance and updates for, probably in December. Yup, it’s got the same heterogeneous tree behavior as the other apps I’ve mentioned. In my book, what should be separate lists of, respectively, source code files, folders, TADS 3 library files, and language constants, are lumped together in a big ol’ tree.

I won’t be able to change Xcode, and I certainly won’t be able to change iTunes, but I can still strike my own little blow against heterogeneous trees.

A Colossal Tease

You’ve heard of text adventure games, also known as IF for “interactive fiction,” right? On my IF page, I mention the (award-winning, natch) games I’ve written, Small World and Rematch. I also mention Colossus, a larger game that was supposed to be the successor, though otherwise unrelated, to Small World.

Most game writers dream of the Big Game, their Magnum Opus: years to write, months to play, a work that advances the form in some significant fashion. An in-depth experience akin to reading a novel, full of fiendish puzzles, compelling character development, and satisfying plot twists. Colossus was going to be that game for me.

I had several ideas about it. It was going to be the IF equivalent of a sci fi blockbuster. I even wrote a “teaser” for it, a mini-game at the start of Dan Shiovitz’s (also sci fi-themed) Bad Machine, released (gulp) going on 6 years ago now. As MacTADS took longer and longer, I thought I would write it in MacTADS once it was finished, using the newer version 3 of the TADS language.

I’m no longer sure that Colossus is what I want to spend the next year or two of my free time on, but hey, who knows?

In the meantime, the teaser’s pretty fun. I may polish it a bit and release it as a tiny standalone game, but the joker is that I’d need to use my old, Classic-only, unfinished MacTADS tools to do it, since TADS Workbench for Macintosh only supports TADS 3 currently. Such is life!

And, please, don’t laugh at the “Fall 1999” release date, OK?

Blinded by the Spotlight

Pretty much a year ago, I wrote this post, and then this post, about downloading Apple’s mailing lists in order to be able to search them better.

What I didn’t do was go the rest of the way and make up a Search Kit-based application to allow for robust queries into all that downloaded data.

Well, there’s good news, and there’s bad news.

The bad news is that I’m never going to get around to it. Hey kids, welching on your promises can be fun!

The good news is that Apple is going to do my work for me in the upcoming Mac OS X 10.4 a.k.a. “Tiger”. Spotlight even uses Search Kit, just the way I would have. The small, individual text files that make up the mailing list download will be ideal for Spotlight.

So now you have something to look forward to. In the meantime, did you notice the new mailing list search UI at http://search.lists.apple.com? It seems to be faster, more flexible, and return better information. As a Web app, it still may not do the thorough indexing that Spotlight would do locally, but it’s available today.

That should keep you out of trouble while you’re waiting for Tiger.

File Imprecations

There’s no dedicated widget in Cocoa for specifying and displaying a file.

Both Cocoa and Carbon apps tend to cobble together custom UI for the task. A “Save” or “Open” button that triggers a Navigation Services dialog, plus a path text field, and sometimes an icon. Apps tend to be internally consistent – CodeWarrior uses the same aggregate widget everywhere, for instance – but none of them quite match each other.

Cocoa apps often do let you edit the path by hand. It seems to me that this reflects the greater NeXT reliance on the command line, and I can see the utility of it sometimes. But I dislike the potential to erase a path by hitting the delete key by mistake. It also seems to me that this sort of thing is better suited to developer apps, where the user can more safely be assumed to have command line expertise.

Carbon apps, with the old Toolbox deprecation of file paths, generally never allow users to type in the path of the file they want: you must use the Open or Save dialogs to specify the file, though the application might then show you the path afterward.

I can actually see something in-between: maybe in the Save/Open dialog, there is a text field, which reflects the full path of the file/folder you’ve currently chosen. You can type in it, and once a name matches, the Navigation Services portion of the dialog moves to that location specified by your typing. Maybe that’s overkill, but it is the kind of marriage of command-line and UI that I’d really like to see. Toss in tab-completion, and you’re all set!

I’m thinking about this because I’m thinking about how I would modify the UI of TADS Workbench for Macintosh if (more like when) I decide to take over its maintenance. I had my own widget in my Isthmus framework to specify and show a file – I even had a specialization of that widget to deal with special file paths, like the “{Compiler}” and “{Project}” paths in CodeWarrior. I will either have to redo that work for TADS Workbench, discard the concept completely, or – most likely – figure out a more scaled-down version. After all, it was trying to make things perfect that doomed Isthmus.

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.

More Shareware: Snapz Pro X 2, SpamSieve, and NetNewsWire

I used to buy a lot of shareware.

Mostly because there weren’t free software alternatives on the Mac platform for the common utilities.

For example, I bought ZipIt, which puts a nice, Mac-like UI on top of standard Zip archive functionality. Remember when you had to do that to get out a Mac port?

I contributed to the Mac version of Opera, though I was disappointed with the result (and especially the attitude.)

But the high water mark was when I paid for Netscape Communicator. Yup, I bought the crappiest Netscape browser ever, which the vast majority of users treated as freeware anyway, less than a year before they made it freeware in name as well as fact. I guess I thought I could support them in the Good Fight against Microsoft. Yeah, that worked.

When OS X came out, it seemed like all the free command-line Linux/Unix utilities that were now available would destroy the market for Mac shareware. Apple would squeeze out the rest with free, polished GUI applications in its bid to remain competitive with Microsoft.

But perhaps the tide has turned. I’ve gotten out my wallet again, for more than just one app here or there. The difference these days is that I don’t need these apps – there are always freeware or built-in alternatives. But they improve my life, and that’s worth something.

Snapz Pro X 2
Goofy name, good product. I’d used it before as part of the OS bundle that comes with new Macs, only to lose it when I upgraded to the next version of OS X. I used the movie capture feature at one point; it was a good way to see what was going on in the first few moments of window initialization in one of my projects.

So I had to decide, this time around, whether to splurge for movie capture or not. It was an extra $40, not a trivial amount.

I finally decided against it. Ambrosia played it right, I think, to make the purchase of the lower-end product plus upgrade not more expensive than buying the high-end version all in one go: I can spend the lesser amount that’s in my comfort zone without feeling I’ll be ripped off if I upgrade later.

I’ve been taking a lot of screen captures lately, since the side project I’m working on requires that I compare pixel measurements to be sure I’ve gotten it right. Apple’s built-in screen capture feature only does PDF files, which don’t scale crisply when you enlarge them. You can convert them to other file formats in Preview, but that’s an extra step, an extra step I finally got tired of. And little touches like being able to set the file owner (in my case, I like GraphicConverter), show or hide the cursor, and turn off the (on repetition) quite annoying camera click sound, were also a nice incentive.

Not strictly a programmer’s utility, but every programmer uses email, eh?

On my copy of Mail, junk mail filtering died mysteriously. Nothing was being marked as junk. I tried the freeware JunkMatcher, but eventually got tired of how it hung Mail when processing large amounts of spam. Sometimes you just gotta pay to get the quality.

Is $25 worth not having to reinstall my OS, and/or tinker and tinker and tinker to get Mail’s filtering working again, and get better filtering to boot? You bet. Less time sorting through mail means more time programming.

Also not strictly for programmers, but blogs are definitely the best way to keep up to date with a wide variety of very smart techies and programmers, most of whom post more frequently than I do. That reminds me, I should update my blogroll, I’ve found a few new good ones.

Heh, am I blazing trails by recommending these two already very popular Mac products? Probably not. But an extra vote of confidence can’t hurt.

One problem I’ve had with NetNewsWire Lite, which I’ve been using for a while now, is that it seems to crash when trying to load some feeds at some times. Not always reproducible, and it happens too fast for me to see which feed it is.

It’s an interesting situation. Do I try to hit up Brent Simmons before I even pay for the software? After all, it’s a show-stopper. Do I move to a different app? PulpFiction seems to have problems with my feed list, too.

I finally decided to pay first, and ask questions later, and here’s the lesson: Brent’s presence on the Web conveys competence, stability, and reasonableness. This is a person I will most likely be able to work with to resolve this, if it continues. Nice guys finish last? Well, this nice guy just got $40.

Does it hurt that NetNewsWire 2.0 has been promised as a free upgrade? Not at all.

Note that the extra features in the non-Lite version didn’t entice me at all. I’m paying to support a good product. If he gets bought by AOL, though, I’m gonna be pissed.

ADHOC/MacHack 19 Report

I had fun this year.

I missed David Pogue’s keynote, though I saw a few snippets from the tape and they looked funny. Steve Hayman, from Apple, did the second night’s presentation, and he was hilarious. He was subbing for Jordan Hubbard, who was having his own “personal denial of service attack” (he was sick).

To my surprise, I co-won Best Paper, which means I get to go there next year with no registration fee. I got to go this year the same way by writing the paper in the first place.

The conference had noticeably fewer attendees this year. Per my sources, maybe half the number from last time around. Otherwise, it seemed mostly unchanged.

People still called the hack contest “the hack contest,” even though officially it had a new name – even the conference organizers had to correct each other.

19 hacks this year. In my impression, the hacks didn’t have the same technical wow factor as previously. There was nothing, for example, like Quinn’s FireStarter from 2002.

Still, I had fun, and the organizers called this year a success.

Would I mind seeing the conference do things dramatically different next year? Nope. Shinkage without change isn’t a strategy you can continue indefinitely. New location? Different format? Merge with another conference? Dunno. If I had any big ideas, I suppose I would’ve volunteered to help run things next year. Since I don’t, I will merely wish next year’s organizing committee the best of luck.

Something in Comma

I was unable to demonstrate my Xcode projects today at my ADHOC presentation. They produced an obscure error when building.


Not because I’d moved the project, or renamed the project or its enclosing folder. Xcode can handle that.

It was because I’d renamed the enclosing folder to contain a comma.

I remember when Project Builder location paths couldn’t contain a space.

This is probably a similar issue having to do with the underlying, Unix-based technologies (i.e. gcc).

I wonder if the fix will involve merely putting in a few more quotes around command-line options, or if it would require deeper surgery.