Programming

Exclusive: New Tiger window style deciphered

April 15th, 2005  |  Published in Macintosh, Programming

Paul Thurrott accidentally wrote a pretty favorable review of Mac OS X 10.4 (”Tiger”). Towards the end, he apparently realized he was losing all his street cred in the Windows world, so he threw in some gratuitously negative comments — “Tiger is in fact a minor upgrade with few major new features, more akin to what we’d call a service pack in the Windows world” — which, apart from being patently ridiculous, supports the not-very-original premise that Apple fans are “suckers” who will immediately cough up the cash for mere glitz.

  • Pretty tough stance for a self-described “Mac fan [his] entire life”; so much so, we learn, that in 1987 he replaced his Commodore 64 with … an Apple IIgs. This was followed by an Amiga; then, when Commodore went belly up, a PC running OS/2 — this is one industry analyst who really knows how to pick winners — and finally, in 2001, an iBook. Pity the poor “Mac fan”, pressing his nose against the glass for fourteen years.

I mention all this as an excuse to use another of Thurrott’s comments as a jumping-off point for an observation I have not seen elsewhere as yet. (Not that anyone’s going to see it here, but at least I’ll be on the record.) By now many people have commented on the new window style seen in Mail, where the title bar and toolbar blend together in a single gradient. Thurrott remarks upon “yet another user interface style”, which he calls “plastic”; others have called this change “arbitrary” or “gratuitous” or “confusing”.

Well, I think I’ve figured out the logic. Here are some applications using the new window style: Mail, Help Viewer, System Preferences, Xcode 2, and the Spotlight window itself. What do these all have in common? The Spotlight search field. The new window style, to me, is a visual cue that the application supports Spotlight as a primary navigation mechanism.

Unfortunately this analysis fails in two important respects:

  1. I haven’t found anything in the Apple documentation that suggests this usage is intentional. (Of course, the Tiger developer documentation hasn’t been publicly released yet.)

  2. A huge exception to the rule is the Finder, whose windows still (inexplicably) use the “brushed metal” style. You’d expect that if a Spotlight cue were present anywhere, it’d be in the new Finder.

Still, this is the best theory I know to explain the new style, and I haven’t seen anyone else mention it, so I hereby take credit for it.

  • On the other hand, Mail’s toolbar icons… I understand why they’re in “capsules” (to allow for toolbar button “groups” — though it makes the non-grouped icons needlessly cramped), and I even know why they’re “centered” (they’re not; they’re left-justified over the message list, skipping over the mailbox source list — a bit of a hack, but having Delete and Junk over the source list is potentially confusing). But I won’t make apologies for them, either.

[2005-04-16: Added Help Viewer to the sample applications.]

[2005-04-22: Well, I could be wrong… see first comment.]

[2005-05-05: Yes, I'm wrong... see second comment.]

EA Spouse speaks out

November 19th, 2004  |  Published in Programming

I’m only just hearing about the EA spouse who spoke out about the increasingly extreme conditions under which the SO was working. At last count this single weblog entry had 2780 comments.

Reading the description of the EA development process from the point of view of a longtime software engineer, my mind boggles at the idea of a “pre-crunch” to ramp up for the “real” crunch, followed by a “super-crunch” — all apparently planned for in the schedule. Folks, apart from being disgraceful and probably illegal, this plain just doesn’t work; engineers get fatigued and you end up with crappy software. And no compensatory considerations for the staff? No money, no comp time? It’s not like EA is a startup company; they’re making money, and they’ve been making games for years. They should know better.

I’ve worked at three different companies, including one in the gaming subindustry. All of these companies were startups or startup-sized, and so the success or failure of any one project might mean the success or failure of the company as a whole. We knew this and reacted accordingly — when the time came, we put in the level of effort needed to accomplish the job, up to twelve- to fourteen-hour days, six or seven days a week. (I tried very hard to keep one day to myself, to protect my own sanity.)

In my experience, we were always compensated for our extra effort in some way, usually comp time or cash. In one case we had a specific deadline with promised bonuses for meeting it, including an extra bonus for the “team MVP.” We were given every opportunity to meet the goal (including moving the deadline back ten days after the server failed in the last month), and everyone got the MVP bonus. (We ended up not shipping for another fifteen months, but that’s another story.)

More meaningful were the “personal” rewards. Once our company president got us tickets to a Celtics playoff game (in ‘85 — Bird/McHale/Parrish). At the gaming company I was given the opportunity to do a personally meaningful project and given a brand-new Mac II and hi-res color monitor to do it with. It’s a cliché to say this can mean more than the money does, but it’s also true.

So why would someone put up with the conditions described by the EA spouse? Sometimes (as in this case, seemingly) they needed a job in a weak market; sometimes they just didn’t know to expect any better.

One more story from early in my career: one Friday the boss asked me to demo my current project at the company-wide meeting on Monday. Unfortunately it wasn’t working yet, but I was young and the boss was new, and I was too intimidated to say anything. So I worked throughout the weekend, giving up going to New York on Saturday to attend a good friend’s wedding — to my lasting shame and regret. (And on Monday? No demo; something else came up at the meeting, and I didn’t speak up.)

[I wrote the above before skimming the comments. Apparently (a) EA's record in this area is widely known, and (b) they're not alone in this. It was nowhere near that at the gaming company I worked at in the mid-to-late '80's. I won't name it here; it's no longer around as an independent concern. If you Google my name you can probably figure it out on your own.]

Followup to first annoying C# thing

August 13th, 2004  |  Published in Programming

My friend Nick dashed off the following quick reply to my previous screed (in its first incarnation as an email message to him):

I think it’s the difference between thinking of it as a verb or a noun.

That would be fine, except they’re using it as a noun. Allow me to quote from Dumbill and Bornstein:

These methods [such as OnFileSystemEvent, which will be referred to later] must match the delegates declared in FileSystemWatcher. From the Mono FileSystemEventHandler.cs [...] source file [...]:

public delegate void FileSystemEventHandler (object sender, FileSystemEventArgs e);

A delegate declaration defines an instance of a class descended from System.Delegate. In FileSystemWatcher, then, FileSystemEventHandler is an implicit subclass of System.Delegate.

So it looks like a function declaration, but it’s really a subclass declaration? (I presume “instance of a class” doesn’t mean “an object that belongs to a class” here.)

… Next, we construct a new delegate of type FileSystemEventHandler and use the += operator to add it to each of the FileSystemWatcher’s FileSystemEventHandler events.

[The code that does this is:

FileSystemEventHandler onFileSystemEvent = new FileSystemEventHandler (OnFileSystemEvent);

where OnFileSystemEvent was previously declared as a static method with a signature matching the one above.]

So what we appear to have is a declaration that looks like a function but really declares a subclass of a special type of object that has only one method and no instance variables. Then you create one of these — things — initializing it with a matching method, and finally attach it to another object in a special way, such that it will be called back when a particular — something — happens.

I’m not saying this isn’t useful, but couldn’t they have presented it a different way, or called it something different (”callback”)?

Maybe I’m putting the blame in the wrong place. The philosophy of the Developer’s Notebook series seems to be to get you writing code quickly, and eschew all the theory. (They even title this section “Define Function Pointers”.) Perhaps I should crack open Hejlsberg et al. and see if they explain it more precisely.

The (first) thing annoying about C#

August 12th, 2004  |  Published in Programming

[I haven't gotten too far into the language so I can't presume there won't be more...]

I want to like C#. I think it has a lot of advantages over the widely used languages that come before it. When it was first released, it was widely believed to be a replacement for Java; but I’m looking at it more as a replacement for C++ — the little things that are peculiar idioms or complex constructs in C++ seem to tend to be directly supported in C#. So I’m predisposed to like it.

But then I come across these annoying Microsoft-isms — specifically, the Humpty-Dumpty-like [1] way in which they define ordinary computing terms like “events” and “delegates” to be something almost, but not quite, completely different.

I know what a “delegate” is — it’s an object that handles behavior for another object. A common design pattern, and one supported pretty much directly in Objective-C and Cocoa. But that’s not what a C# delegate is, apparently — although I’m not sure exactly what it’s supposed to be. It’s “like a function pointer”, except we don’t have those in C#. And the first example I see (in Mono: A Developer’s Handbook) suggests that the thing you declare as a delegate is really a prototype for the action that the actual thing you instantiate is supposed to take — huh? Wouldn’t that be the delegate?

And apparently an “event” is a collection of delegates, and not, well, an event.

And somehow delegates are magic so you can instantiate one, add it to an “event”, then later instantiate a different one and remove it from the same event, and the “right thing” happens. (Because they’re “like function pointers”.)

Maybe this will make sense if I keep reading. (I hesitate to crack open The C# Programming Language, which is also on my desk; I’m a bit of a programming language nut, but this one looks like I need a law degree to get through it.)

[1] I could have said “Orwellian”; aren’t you proud of me?