Friday, June 24, 2005

Neat tricks

Here are two neat features of my PowerBook:
  1. I have used a mouse with a scroll wheel (under Windows) for years now, and I find it surprisingly frustrating to ever be stranded without one. Mousing away from whatever you're doing to use window scroll buttons is time consuming. Worse, for a while after starting to use the PowerBook, I would instinctively mouse over to the top of the scroll bar when I needed to scroll up, but by default the buttons are stuck together at the bottom of the window. Completely by accident, I discovered that moving two fingers up or down on the PowerBook's touch-pad scrolls the current window up or down. So now I've basically got a scroll wheel mouse. Firefox (but, as far as I can tell, not Safari) will also go forwards and backwards through hyperlinks by moving two fingers left and right. So no I've basically got a scroll wheel mouse with left and right side-buttons.
  2. Although it's got a lame, marketroid name (Exposé), Mac OS X's window-handling features are significantly more useful than Windows XP's. Sure, it does the standard Alt-Tab cycling (and Shift-Alt-Tab for reverse), but there's more. F11 temporarily clears the screen and exposes the desktop. Sure, Windows XP has a button to do the same thing, but I've never found a way to get the windows back using XP—no doubt one exists, but it beats me what it is. You can isolate just the windows of the current application with fn-F10. This dims the remainder of the screen, and brings all the current application's windows to the foreground, but, if necessary, shrinks them enough so that they can all be seen (possibly in miniature) at once. You can then select the window you're interested in. fn-F9 does this for all the currently open windows. (This is the kind of neat advantage you get when the operating system knows exactly what the graphics hardware is going to be, every time.)
Maybe every laptop with a touch-sensitive mousing area can do number 1, and maybe Windows XP can do some near-equivalent of number 2. Who knows. They're still neat tricks.

Tuesday, June 21, 2005

Unconventional wisdom

There was an interesting post on Professor Dave Farber's Interesting People (IP) mailing list earlier this month entitled "Steve Jobs' Stanford Commencement Speech". Apparently it's authentic—at least, no one's debunked it yet. It doesn't really matter if they're not Jobs's words, though, since the content seems to be widely acknowledged (on the IP list, at least) as the kind of story Jobs tells about the development of the Mac. Even more interesting than the original post, though, are the numerous follow-ups it generated. (You can read the follow-ups on the June 2005 archive page for the list. As an aside, unfortunately Prof. Farber runs the list by forwarding contributions to the list with altered subject lines, not by moderating submissions with decent mailing list software, so threading of messages is really poor. You'll need to find the follow-ups by searching for "Jobs" on the June 2005 archive page.)

I didn't know the history of the development of the Mac was so controversial, yet I guess I'm not really surprised. In my recent, pre-Mac past, I read "The second coming of Steve Jobs" by Alan Deutschman, a book that paints a reasonably negative picture of Jobs. To read claims that the conventional wisdom (roughly: Jobs visited Xerox PARC, came back to Apple and invented the Mac) is revisionist shouldn't come as a surprise, but, despite most of these claims being a decade or more old, they did. I guess that's the thing about conventional wisdom. Most people believe it.

I gather it doesn't stop there, though. In the last few days, I've read posts by (the late) Jef Raskin, and a response by Bruce Horn. Some of the facts differ in their accounts—and these guys were there at the time. I guess part of the problem is that any development effort like that was certainly a non-linear exercise. It's not just unsurprising that one person can't get the record exactly right, it's not really possible for them to do so. (Except if you're Steve Jobs.)

Friday, June 17, 2005

File type associations

I think I have reached the first point with Mac OS X where I am confused. I was going to say slightly confused, but I think I may be completely confused. And its the issue of file type associations.

As with every post I make, let me start with some background. In the Unix world, given some file 'foo', there is essentially no metadata associated with that file that tells me or the operating system what application (or range of possible applications) I should use to operate on that file. That is, you can certainly call a file pretty much anything, and there's no background magic telling Unix how to open that file, or what to display or edit it with. (It's not as bad as it sounds. As you would expect, conventions develop, and there are utilities (such as 'file') that use magic to determine file types for you if you're stuck.) I'm not saying there aren't 'file extensions' (like putting '.jpg' at the end of a JPEG file), I'm just saying that there's nothing forcing that behaviour, and nothing automatically arises out of you doing so.

In the Windows world, as far as I can tell, the famous MS-DOS '8.3' legacy is essentially alive and well, though the numbers there are a little larger. But the principle remains: Windows uses 'filename extensions' to associate a file with an application which can operate on it. If a filename ends in the literal string '.jpg', then that file is a JPEG image (and you can't really convince Windows otherwise). While this strikes me as a little inelegant, it works in practice about 99% of the time. (Here's an example of the 1%: you can't (again, as far as I can tell) convince Windows to do anything sensible by default with a file that has no filename extension. Once I tried to convince Windows XP to open extensionless files with a text editor—which, for me, would work most of the time (e.g., 'README'—it's not a 'README file', Windows, it's text—just take a look)—but couldn't.)

My understanding of how this all works under Mac OS X is fairly shallow, though I do gather there is quite a bit of metadata associated with every file. What I don't seem to have mastered just yet is manipulating it. I had the Microsoft Office trial on the PowerBook at purchase time. It expired, I removed it, and installed the full version. Now, Tiger seems to be confused about how to open Office files. I have a Word document attached to an email. From Mail, I clicked on the document, and got this response:


How odd. Is this Mail's problem? Is it Tiger's? How can I find who is trying to hand the document off to whom? Next, I choose 'Save', and double click on the document in the Finder. Even the Finder is not going to play nice:


Now, don't get me wrong—I love a good cryptic error message (preferably with a negative error number) as much as the next guy. But this is starting to get a little too Windows for my liking.

Anyway, back to the document. I Ctrl-click on it (yes, I am a power user now):


OK, so Tiger thinks there are two possible versions of Word. I started thinking, "Presumably one of those was the trial version, and the other is the full version." Then I started thinking, "Why should I even care?" At this point I slumped back in my chair. I bought a Mac to get away from all this Windows-esque stupidity.

There is a happy ending to the story. After burrowing around in Finder preferences, system preferences, file information dialogs, and probably a few other places, I got pretty much nowhere. The negative error number dialog was obviously completely useless, and it's the kind of Windows-style user interface element of which Apple ought to be ashamed. However, after Ctrl-clicking the document and trying the suggested applications one-by-one, I finally got a useful error message: the problem was that the trial version of Word was still in the Trash. That was it. Empty Trash, no more problem. So, the summary is this: I'm happy, but it shouldn't have been this hard.

Tuesday, June 7, 2005


Lots of the cool kids have been talking about rumours of Apple switiching from PowerPC to Intel processors for the Macintosh, and some of the coolest kids have been saying, "I doubt it." For what it's worth (which isn't much, since a month ago I didn't own a Mac and didn't know a Finder from a Spotlight), I was saying, "I doubt it," too, albeit only to myself. But, it seems, it's true.

Here's a prediction: I think this will turn out to be a mistake. While Intel's x86 line has certainly proven to be a very popular microprocessor, having its legacy stretch all the way back to 1978's 8088 is surely going to prove brittle eventually. Consider how the unnaturally long dependence of Microsoft Windows on DOS crippled the former for years on end.

Of course, I have a bad track record in technology predictions. I still remember the first time I read that someone was experimenting with transmitting graphics over HTTP for use in web pages. Using lynx at the time, I still recall wondering, "Who on earth would want to see graphics on a web page?"

Friday, June 3, 2005

Pain-free GUI building

I have been pounding away at code examples in "Cocoa Programming for Mac OS X" (ISBN 0321213149), a book by Aaron Hillegass. (For anyone who's interested, it's certainly so far an excellent book for people who, say, know some C or Java, but don't know Objective C or even anything much about Mac OS X.) I want to make an observation about Mac OS X which I think is neat, but I had better preface it with a short description about my Java experience, just in case it turns out that the observation is not that neat, and, in fact, I've been doing things the hard way all along.

I have written quite a few lines of Java code over the years, the majority of which has been console-based tools and applications. However, I've written the odd toy, and collaborated on a single substantial project, using Swing to create graphical user interfaces (GUIs) for Java programs. Further, I've never been a fan of great big, hulking integrated development environments (IDEs). And that's not through a lack of trying them out, starting way back with Sun's Forte. I'm more of an emacs kind of guy, and even in the large Swing application, we built the GUI by hand—that is, by typing in the code to build the GUI bit-by-bit. It was, well, awful.

Enter Apple's Xcode. Xcode is a great big, hulking IDE. But it's free, and it comes with good documentation, and Hillegass's book has been stepping me through it. There are (some) emacs key bindings in its editor, and they're getting me through the withdrawal. Finally, here's the neat bit. There's a tool called Interface Builder for putting together the GUI for applications. Nothing remarkable there. Instead of generating code to recreate the GUI at run-time, though, what Interface Builder does is this: it allows you to construct the actual object hierarchy for the GUI in a drag and drop fashion (which is probably what the Java IDEs are doing as well), and then just serialises that object to a file for reconstruction at run time! That is, it doesn't translate the object hierarchy you built into code to reconstruct that hierarchy, which is the only way I've ever seen a Java IDE do it, it just serialises the actual instance of the object hierarchy you've just built on-screen (or "archives" it, in Apple-speak) for deserialisation ("unarchiving") at run-time. I think that's neat.