Tagged: From Old Helpful Tiger Blog

Sit, Ubu, Sit! Good Dog

Note to Macintosh developer community:

The days of the .sit file have passed.

StuffIt Expander isn’t even included by default anymore on new Mac OS X 10.4 “Tiger” systems. You have to download it separately.

Now, I will admit, this is easier than it was even just a year or two ago. Allume Systems (née Aladdin Systems) used to make it incredibly difficult on their Web site to even navigate to the free Expander download. And the download was in fact not Expander, but rather StuffIt “Standard,” which included several additional shareware products most people didn’t want. The philosophy seemed to be, “If we just piss off our users enough, maybe they’ll buy something from us!” Ugh.

When I just tried to download StuffIt Expander 10, however, I was able to get to the download in two clicks, and the resulting installation was Expander alone. So that has improved.

But you’re still requiring your users to find and download a third-party application just to get to your product.

If your product is Mac OS X 10.3 “Panther” and up, the solution is easy: use the operating system’s built-in “Create Archive” contextual menu in the Finder to build a .zip archive of the files you want.

Now, if you’d used the command-line zip utility on Mac OS X 10.2 “Jaguar” or earlier, you would’ve found that it ignored Mac-only filesystem attributes like resource forks. “Create Archive” is smarter than that. If you double-click such an archive in the Finder, it will extract the archive contents, resource forks and all.

The downside? “Create Archive” uses a custom directory layout (presumably in order to organize the extra bits) which will look strange if you attempt to open that archive with a more traditional command-line zip utility, even the zip utility at /usr/bin/unzip on that same OS X 10.4 “Tiger” box where you made the archive in the first place! (Not to mention the zip utility on 10.2 and earlier.)

This means that these .zip files, which by their suffix look nice ‘n’ cross-platform, really aren’t. They’re still primarily for delivering content to Mac OS X users. Your sole benefit is that the archive will be double-clickable on 10.3 and higher, without additional downloads.

If you need to support Mac OS X 10.2, well…I hear StuffIt Expander is easier to download than it used to be. Oops! You have to go back to StuffIt “Standard” 8.0.2 to get Mac OS X 10.2 support. It looks like they require you to join their mailing list just to download the damn thing. Tough luck….

My advice? Make a .dmg file.

A TADS TADS TADS TADS World

The TADS interpreter scene on Mac OS X is a bit like the browser scene. There are more of them than you’d expect for a minority platform, and they embody different philosophical approaches.

The saying goes: “Cheap, fast, or good: pick two.” I tried “perfect” with my MacTADS project and wound up never finishing it at all, so it’s no surprise that the authors of the following interpreters made a different set of compromises in order to get their applications out the door.

(The observations below are more about the UI than a detailed review of gameplay.)

QTads
First, Nikos Chantziaras wrote FrobTADS, a command-line port of TADS that replaces the old, crufty port mentioned in this post and used in Uli Kusterer’s TADS Workbench for Macintosh.

Second, he built a GUI TADS interpreter on top of that, called QTads. As ANSI C and POSIX are to FrobTADS, Trolltech‘s Qt library is to QTads: if you support those APIs, FrobTADS and QTads respectively can be built for your platform.

This approach led to a full-featured interpreter for the Mac platform without needing someone to commit full-time to it. QTads even has some niceties not in other Mac interpreters, such as a font/color “preview” panel and theme sets.

The downside is that QTads is a Mac application the same way Eclipse is a Mac application. Colorful, but not exactly native-looking:

QTads Game Menu Screenshot

Huh, an Exit menu item? Never fear, there’s still a regular Quit menu item under the Application menu, but this goes to show we’re not in Cocoa anymore.

As another example, have a look at these two lower right-hand corners of windows:

QTads Lower Right-Hand Window Corner NetNewsWire Lower Right-Hand Window Corner
QTads NetNewsWire

QTads has an ugly black outline around its main scroll view, and its window grow box is half the size of a native Macintosh window grow box. NetNewsWire’s version is provided for comparison.

Finally, if you resize the window, you’ll notice some flickering. QTads eschews OS X’s double-buffering, and instead erases and redraws the edges of its window right before your eyes.

Some of this might be fixable with more work on Qt, but some of it is a deliberate, un-Mac-like style that comes with the territory.

Cugel
Cugel’s author made a different set of compromises. Native? Check. Full-featured user interface? Well, not really. For example, there’s no status bar area at the bottom for a “more” prompt. Such a bar doesn’t come native with the Cocoa scroll view, which is why my in-progress Neutrino main window doesn’t have one yet, either.

But what you get instead is a “Unified Interactive Fiction Player.” It can play not only TADS games, but also Hugo games, Alan games, Glulxe-based games (supported by Inform), and others.

It’s actually pretty cool to look in the Cugel package and see the individual interpreter utilities for all these languages.

Ben Hines MaxTADS OS X port
Ben Hines made a third set of compromises. My impression is that in 2002, he saw that there was already a perfectly good OS 9 TADS interpreter, Andrew Plotkin’s MaxTADS. He also saw that Apple provided a quick way to port such Toolbox-based code to OS X, the Carbon APIs.

So he “ported” MaxTADS to Carbon, and by “ported” I mean that he made the fewest changes possible to the codebase and resources so it would build and run as a Carbon application on 9 and X. The UI remained entirely unchanged, and it looks more and more anomalous on subsequent versions of OS X. For example:

MaxTADS Carbon Port UI

Yes, that’s a System 7-style textbox you see!

Here’s another issue. Two quit menus:

MaxTADS Carbon Port Menu

The Cmd-Q keystroke shortcut does nothing, by the way. You have to select the menu item by mouse.

The upside of all the hurried work? This was the very first native OS X TADS GUI-based interpreter. The other two interpreters mentioned above were released two years or more after this MaxTADS port.

..Than a Speeding Neutrino

I’ve talked about my travails using Subversion and getting unit testing set up. I was mysteriously vague about what it was all for…

…Until now. (Cue ominous music!)

It’s for an application called Neutrino, which will allow you to do something on a new Mac 1-2 years from now that you otherwise wouldn’t be able to do.

Word by Word
Neutrino is a TADS multimedia interpreter written in Cocoa using Xcode. Let’s break that down:

TADS: “Text Adventure Development System,” a special-purpose programming language, library, and virtual machine for both writing and playing interactive fiction a.k.a. text adventure games. Wikipedia has some history on it.

multimedia: When TADS was first introduced, it was strictly T, for textual. Its author, Michael Roberts, eventually decided to add some multimedia capabilities to it. He called it HTML-TADS, because the way to add these elements was via a simplified and customized form of HTML markup. There are only two interpreters that can fully display such content, the TADS interpreter for Windows that Michael Roberts himself wrote, and HyperTADS for the Mac, by Iain Merrick.

interpreter: TADS source code is not compiled to native CPU instructions, nor does it use specific operating system APIs. Instead, it’s compiled to be played in its own virtual machine maintained by a platform-specific interpreter, like Java source is compiled to run on a Java virtual machine.

Cocoa/Xcode: Because Neutrino is written using these technologies, I will be able to release a “universal binary” version of Neutrino, that will work on both PowerPC Macintoshes, and the Intel Macintoshes that will be released over the next several years. (Carbon/Xcode would be another possibility.)

History
For TADS’ early history, the sole Macintosh interpreter was also maintained by Michael Roberts. It used the early Toolbox TextEdit APIs, though, so it was limited to 32K of text scrollback. Plus, it didn’t display any styled text at all.

Once TADS went open source, Andrew Plotkin wrote a new interpreter for it, called MaxTADS. It had all the bells and whistles and matched in both style and name his interpreter for Z-code games, MaxZip.

When HTML-TADS arrived, HyperTADS was written to handle it, since MaxTADS remained text-only.

This all happened before OS X was released.

Current Interpreters
Today, there are three native TADS interpreters that I know of for OS X. Ben Hines did a quick-and-dirty Carbonization of MaxTADS in 2002. Recently, the more substantial ports QTads and Cugel have been released, and are under active development. I do a more thorough review of these interpreters (or at least of their UI) in this post.

So the native interpreters won’t display multimedia game content, and the one Mac multimedia interpreter is non-native and won’t run on Intel Macs.

Answer to the Riddle
If you buy a new Mac 1-2 years from now, and you want to play HTML-TADS games like Six Stories or Arrival or Exhibition to their fullest, you will be out of luck, unless I get my ass in gear and finish Neutrino.

Oh, yeah, one last note: it’s not finished yet. In fact, it’s probably about 10-25% done. But here’s a screenshot:

Neutrino Screenshot

Honey, I Shrank the Partition!

Luis de la Rosa asked in a comment to this post about my experience resizing partitions.

Before Monday, my experience was nil. The Mac traditionally hasn’t had utilities that can resize partitions, and OS X especially has had none.

That’s changed. Now, there’s VolumeWorks ($59.95) from SubRosaSoft and iPartition ($44.95) from Coriolis Systems.

iPartition is cheaper: is it better? VersionTracker says so, 4 stars versus 3 stars. I decided to buy it and try it.

First of all, it doesn’t come with a bootable CD. The Web site directs you to BootCD by CharlesSoft, but that is not compatible with Mac OS X 10.4.

I got around this problem by attaching my laptop to my tower via a firewire cable and booting the laptop into target mode, so the partitions showed up in the Finder on the tower. iPartition can resize the partitions of a drive connected via FireWire just fine.

First, I copied the entire contents of all the laptop’s partitions to my tower. I used cp from the command line: on 10.4, cp will also copy resource forks.

I also used Apple’s Disk Utility application to make sure all the laptop partitions were OK.

I used the bundled program iDefrag Lite to compact the used bytes of my data partition, then used iPartition to shave 15 Gb. off of it and distribute them to the three system partitions. The UI for this in iPartition is especially nice: you drag the sides of brightly-colored pie wedges representing the partitions on disk to make them bigger or smaller. A selected “slice” is half-removed from the pie, so it’s easier to see and manipulate.

All the steps together took maybe 8-9 hours.

I rebooted the laptop, and haven’t had any problems yet.

svnX: A Review

svnX looks like it’s the most full-featured GUI Subversion client on the Mac. Nate Silva asked me about it way back in this comment in my first Subversion post. So, how is it?

It’s got a good deal of the functionality I want.

• I can see the state of the files in my working copy: modified, added, removed.

• It supports visual diffs, and for extra points, it supports all the major external apps that provide this.

• For a repository, it can show me all the files affected by a particular check-in. It supports deleting, moving, and copying files in the repository.

All in all, it’s a workable replacement for Xcode’s Subversion support. That’s how I use it, as an occasional replacement, to deal with the Subversion work I need done for files that aren’t in my Xcode project.

Now, before I get to what I don’t like about it, let me acknowledge two things.

One, svnX has been released under the GPL. I could dive into the code myself and fix the problems I’m going to describe. Unfortunately, I’m already in the middle of a project – that’s what I’m keeping in my Subversion repository, and why I need a Subversion client! That said, I may take this up at some point.

Two, I want to keep my criticism of the application separate from the application authors. I treat the failings of a project like this, done for free and presumably in one’s spare time, far differently than I would treat even a shareware application.

I said svnX had most of the functionality I need. But in the realm of polish, it is disappointing, shocking even.

Have a look at the screenshot of the repository window. Notice anything strange in the uppermost table? What’s that first column of radio buttons doing there? To do a diff between two check-in versions, I shit you not, you need to select one of them via the radio button column, and the other by a more normal selection highlight, and then click the FileMerge button.

Why is the UI set up in this bizarre manner? I don’t know for sure, but my suspicion is because it was easier. In Cocoa nibs, tables can be set to allow only single-row selection, or multiple-row selection. Multiple-row selection, as you can imagine, involves a lot more work to handle all the different possibilities. But it’s what users expect.

Actually, I simplified things a bit. Hitting the FileMerge button doesn’t go directly to a file merge. It actually brings up a sheet with exactly the same two tables that are at the top of the window the sheet is attached to, from which you have to select the versions you want to compare. What does that sheet refer to? It turns out, it refers to the file selected in the third table on the main window, though the sheet gives you no indication of that. You can’t multiple-select in that file table, either, so you can’t do several file comparisons at once.

svnX has separate windows for Subversion repositories versus Subversion working copies. You can see a screenshot of the working copies window here. You’ll notice this window is much more simple. The repository history is completely unavailable. All you can know from this window is whether any files have had changes made to them since the last check-in.

Again, I’m assuming the reason this was done was to make things easier. It would be much harder to create an intuitive user interface where the information about a working copy is overlaid on the repository itself…but that’s what I want.

I want to be able to compare my working copy file’s condition against what was checked in 10 revisions ago. I want to be able to see what check-ins were made on the files that I have edited, in the same table – a column you can hide, perhaps, so it’s not always cluttering up the window?

I want to be able to perform file and folder moves in the working repository before checking them in: right now, you can only do that in svnX in the repository window, where changes are immediate.

I want to be able to go from the row representing the file to the file in the Finder. Contextual menus seem totally unsupported.

There’s probably more, but this will do. Some of this stuff is small potatoes, but if I were to work on this, I’d want to tackle the big stuff first, which would probably mean rewriting a lot of the UI code. Not something to be undertaken lightly.

Before I go, I’m going to have to take issue with the name. “svnX”? You name a GUI application after Subversion’s crypticly-named command-line tool plus an “X” to show it’s on Mac OS X? Is that the best you can do?

Here are a few suggestions, marked as (taken) if I found an app with that name in http://VersionTracker.com:

“Subversion” sounds like “Subversive”, right? So how about: Saboteur (probably not), Instigator, Agitator, Provocateur (I like that one).

You’re gaining access to an otherwise unreachable destination, like a castle, right? So how about: Drawbridge, Bridge, even Moat.

It’s a record of changes, so how about: History (taken), Historian (taken), or Archiver. You use it to find or figure things out, so maybe: (Code) Detective, Codehound, maybe even Code Thief.

Finally, I’ll end on a positive note: I like the swirly blue icon.

Subversion Immersion: Changing How I Write My Home Projects

One of the things that sank my MacTADS project was that I let my perfectionist tendencies take over. It wasn’t enough to have things work: the files had to be formatted exactly the same way, had to use the exact same techniques everywhere, had to have exactly the right behavior.

I didn’t use an SCM system then.

Now that I’m using Subversion, I’m finding something pretty cool: the rewriting tendency is more easily resisted.

Instead of letting one thing lead me to another, and then to another (“OK, I’ve fixed that bug, but I’ve noticed this other inconsistency, I’ll just do a big find-and-replace to regularize that….”), I now have to stop and think, what kind of comment would I check that in with? Does it really make sense to lump together this two, or three, or five different changes? When I started out only wanting the first? All right, then, undo the beginnings of the other changes, check in what I have, and call it a night.

Now, if I didn’t care about the organization of my Subversion repository, this wouldn’t be a problem. I might not even use comments for my checkins! (There’s a circle of Hell reserved for such people, btw.) But I’m a perfectionist, remember?

Now, I haven’t yet turned this into greater productivity. I’m not getting things done faster. But I do think I’m avoiding getting things done even slower….

Any Sufficiently Advanced…

Others have commented on how the style of the iTunes 5.0 interface is different than any other Mac OS X 10.4 “Tiger” application. What’s more interesting to me is the contents of the new interface.

They finally added groups! I mean, folders. But they kept most of the wacky, colorful smart groups, I mean, sources, from 4.9:

iTunes 5.0 Xcode 2.1
Xcode iTunes iTunes Xcode

All of this leads me to rule #1 (No, not that rule #1!):

Any sufficiently advanced Mac OS X application is indistinguishable from Xcode.