Code and cars

Cars are primitive things. Sure, newer models have more features, with bright, fancy displays and microprocessor-controlled ignitions. But at its heart, a car is simply a series of controlled explosions, and everything around it to harness them. More to the point, certain systems of cars haven't advanced much in the last 50 years. The largest innovation in car batteries during this time appears to be the addition of a carrying handle. And yet, the charging system is one of the most misunderstood parts of a car.

Perhaps this is because it's understood at all. Nobody thinks about an oxygen sensor, not even when the check engine light comes on. Among belts, chains, wires and pumps under the hood, the battery is rather obvious. A battery's purpose is well known, and there's a warning light for it. The light that lies.

One of the mixed blessings about developing software for the mac is that there's high user interface standards. And, more or less, a push for consistency. This is good in one way. Any good framework will already handle drawing of most items. Buttons, menus, tables, etc. Cocoa throws in more things for free, like spell checking and drag-and-drop for text fields and the like.

But what about things not in the framework? Custom controls and displays? Throwing in code is the easy part; the hard part is knowing what it should do; the behaviors and graphic styles necessary. One of the biggest request for help on the dev boards, and tools offered, is to recreate the look and feel of some of Apple's programs in order to maintain consistency. One of the biggest features of Leopard that won't be trumpeted is pushing aside aqua, brushed metal, and a few other window designs in exchange for a single consistent window style.

The project I'm working on has something akin to a file browser in it. It's different enough to merit its own custom code. This means looking at how the finder handles selection and dragging. Since I don't have the 10.5 seed, I took a look at how the 10.4 Finder does things. I've used macs for years, and it's only now that I noticed this very strange inconsistency in how it's done. Here's to hoping they FTFFed in 10.5.

My desktop machine is an upgraded, yet still old Blue and White G3 mac. For the longest time, I used the tried and true ADB Mouse II, with simple curves and a single button covering the entire top.

Currently, however, I use an optical mouse from some unknown manufacturer. It's got pretty blue and red LEDs, two buttons and a clickable scroll wheel. The scroll wheel's button is set to "Application windows" in Expose, and scrolling with the wheel is almost indispensable.

And yet, I'd still argue that, at the heart of things, Windows, Mac, and even linux GUIs are one-button systems, the extra buttons a waste, hardly justifying the added complexity and support costs.

Normally, I'd package this more than just a slug of code, but this is too cool to delay and delay, editing and whatnot.

In the Finder, when you're dragging files from one window to another, after a while, the dragged-to window comes to the top, so that you can better figure out where to put it. This happens even if the Finder isn't the foreground app. This would be cool if other apps did this, as it's quite useful. And spiffy.

Cocoa has some very strange properties that others have commented on. First, it's not something you can simply read and remember. It's something you guess and reference, but that's a good thing. Second, if it's getting difficult, you're probably doing it wrong. Third, it's eerily easy to do difficult things, most of the time.

So, copying this behavior would be tough, requiring timers and extra events and such, right?