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.)
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:
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 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’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:
Yes, that’s a System 7-style textbox you see!
Here’s another issue. Two quit menus:
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.
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:
All of this leads me to rule #1 (No, not that rule #1!):
Any sufficiently advanced Mac OS X application is indistinguishable from Xcode.
The reorganization of source files and their enclosing directories in large commercial projects tends to be nasty, in my experience.
1) On Macs at least, they use CVS as their source code management (SCM) system. CVS can’t handle moving files and folder gracefully. At best, you delete the files in one place and check them in somewhere else, which abandons their history in the original location. And you can’t delete directories at all. Instead, you leave the old, dead, empty directories there and instruct everyone to use
-P when they do their checkouts and updates, so that empty directories are pruned for local repositories.
2) The major IDEs on the platform treat the visual representation of the Groups & Files in your project as something entirely different than the actual files and directories on disk.
“Groups” (yellow folders) in Xcode are only meaningful as an in-project organizing principle. Moving them, or the file representations within them, around in your project window, won’t change what’s on disk.
And conversely, if you move files and directories around on disk, the project won’t automatically be updated to the new arrangement.
So for a reorganization, after you move everything around on disk, you can look forward to doing the exact same thing again in your IDE user interface. This, as you can imagine from how I’m describing it, frustrates me to no end. But it gets worse.
For newer projects, you can fix 1) by switching to Subversion, where both files and directories can be moved around easily with complete retention of their history. But you can’t somehow execute the moving around Subversion commands in the Xcode UI itself, because of 2).
Why did anyone think keeping Groups & Files completely unrelated to disk directories and files was a good idea? Every commercial project I’ve ever worked on has made its Groups & Files tree mirror the on-disk directory structure whenever possible – the only times they diverged was due to maintenance error.
The only good reason I’ve had for a different Groups & Files structure was for a library where all the library headers needed to be available in the same top-level directory. So on disk, it was an undifferentiated list, but I used a 3-4 level deep group hierarchy in the project itself to be able to organize the files better conceptually. But, as I said, I’ve never seen this in the wild.
I’ve just seen hours upon hours spent maintaining hierarchies in two places, both for project creation and the inevitable reorganizations that followed.
One problem I had tonight trying to set up an Xcode project for my previous post was in trying to set up the embedded framework.
The instructions on Apple’s Web site, Creating a Framework: Creating a Private Embedded Framework, are good as far as they go.
They say to add your embedded framework to two build phases in your application’s target. First, the Frameworks & Libraries phase, which makes sure the framework gets linked properly. And second, the Copy Files phase that copies the framework into the application bundle.
Now, the instructions emphasize that, for step one, you have to drag from the Products node, not the Target node. But they don’t emphasize the same thing for step two. I tried to accomplish step two by dragging the framework icon that was now in the Frameworks & Libraries phase into the Copy Files phase.
What I was expecting this to do was put a second representation of the framework in Copy Files. What it actually did was move the framework representation from Frameworks & Libraries to Copy Files. This gave me the impression you could only have one framework representation in your build phases – maybe putting it in the Copy Files phase was enough, it would automatically link it? (Nope.)
It turns out that if I’d dragged the framework from the Products node again, I would’ve gotten the framework representation duplicated in both phases. But what I also found, from playing around with it, is that starting the drag from Frameworks & Libraries, then holding down the Option key, turned the drag into a copy drag (cursor turns into a green plus sign), which has the same effect.
A copy-drag?? I complained here about using a single tree to represent a series of unlike objects. But this is even worse; unlike objects that look exactly the same. The same framework icon appears under the project sub-tree and the Targets sub-tree, but it represents two fundamentally different things – an actual file versus a build phase value. Which means different drag behavior. Even though they look exactly the same.
What have I been doing with all this free time I accumulate by not writing weblog entries for weeks and weeks?
Playing Myst IV, of course!
I won’t be the first person to talk about its interface flaws, but talk I will:
1. No access to regular application menu. This means going through their clunky custom interface to open and save games and bring up preferences. This has gotten worse since previous Mysts.
2. Purty, but clunky “camera” interface. No Undo/Redo for deleting pictures. Ouch! And who needs full-motion transitions just to look at a damn picture! Why do I have to move the mouse, with difficulty, in a circle to switch pictures? Forward and back arrows, hello?!? I love being able to take pictures, but the interface is horrible.
3. Degraded zip mode. Before, you could hover your arrow on a distant location, and if you could “zip” there, it became a lightning bolt. Now, instead, you have to pick a new location from a tiny tiny strip of limited, obscure location pictures. You have to memorize what miniscule image goes with what location, and click the tiny tiny scroll arrows if the list of such images is over 4 or so. In theory, this could be better than the lightning bolt, because it lets you go anywhere. In practice….
4. No automapping. Why doesn’t any game map for me as I go? I spend hours tracing everything out to make a coherent map, guessing whether a gentle turn means 90 degrees or maybe just 45 degrees, hoping the damn paths all link up in the right places when I’m done. I can’t use my own graphics program to help, because Myst takes up the whole damn screen! Is the exact layout of all the locations a state secret? No? Then why act like it! And annotate the map, too. I don’t want obscure florid icons where I have to make a second map just to describe what the in-game map really means.
Those rants may lead you to believe I hate Myst IV, but in fact I’m enjoying playing it. The continued greater and greater use of motion in each successive Myst is a lot of fun. Not particularly realistic, but fun. And the art and music are always great. The acting somehow never seems to improve, but it’s no worse than your average Sci Fi Channel show.
I’m not done, so no spoilers in the comments!
This is the second time (at least) I’ve learned a useful UI tip from a Helpful Tiger reader.
Second was the ability to open a folder from one window in a different new window. Now, Henry Maddocks suggested I use the “always new window” Finder mode, but while that works OK in OS 9, the Finder windows in OS X are just too heavyweight to make that the norm. Now, my case below is better supported by this feature, since as far as I can see it’s something that can only be found in the Help by an explicit search.
Finally, today, a coworker told me about Cmd-tilde. What does this do? It brings to the front the next window in the foremost application. But it’s not in the Window menu of any application.
What do all these features, especially the second and third, have in common? Obscurity. This isn’t something new to X; 9 had its share of techniques you needed to find out from friends or mailing lists.
But X is the new guy, the one getting the ongoing improvements. It has lots of really cool features. So it shouldn’t hide them!
I want every keystroke shortcut and mouseclick/keystroke combination to have a contextual menu item. I want to be able to find out how to do things by exploring the interface, not by reading the help, however thorough it is and well it’s written.
So let’s move on to my next UI pet peeve^H^H^H^H^H^H serious issue.
I open one window, say a column view window, and navigate the filesystem hierarchy to a particular location. I see that location’s contents in the window.
Let’s say at that point I want to see, side by side with the original window, the contents of a location next to the original location. Two locations, same parent folder.
In Mac OS 9, this was trivial:
- Double-click the folder icon representing the sibling location, and it pops up in a new window.
In Mac OS X, to my knowledge, it is not trivial.
OS X thinks of Finder windows as separate working sessions, not as locations. Each session is distinct, and sessions don’t need to talk to each other.
Here’s the way I’ve figured out to do it:
- Drag the folder icon representing the sibling location into Terminal.
- Remove, by hand, escape characters preceding spaces anywhere in the location’s full path.
- Select the path and copy it.
- Open a new window.
- Press Cmd-Shift-G to invoke the “Go to the folder:” sheet for that window.
- Paste in the full path and hit the Return key.
Now, for locations that are easy to navigate to, this is overkill. Instead, just open a window to the same base location and navigate the same way as you did to get to the original place. But that’s a pain, and inelegant to boot.
Better solution? An “Open in New Window” folder contextual menu item would do the trick.