About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Hotspots

A Litter of Nitwits

According to the rumour mill Apple hired on a litter of nitwits to complete Leopard. Is this true?

Get It

Try It

There's a controversy brewing online. There are those who claim Apple hired on a litter of nitwits to complete Leopard. These people were supposedly given what was regarded as a trivial task: run legacy Cocoa code through a 64-bit filter and make sure things work all right afterwards.

What's happened instead - and everybody sees this - is that the code is not merely upgraded to 64-bit but that it's been functionally changed after all these years of establishing 'expected behaviour'.

Today with Leopard there's no 'expected behaviour' anymore - Leopard itself is 'unexpected'.

So that's the claim. Does it have any substance? Here are some of the proofs offered. You be the judge!

Proof One — Table View Mnemonic Nitwits

OS X introduces mnemonics for table views and outline views with Leopard. Unfortunately they don't work. Not only do they erratically go anywhere at all but they're bound by a full second timer to do anything. Clearly the persons who designed and wrote this code are full blown idiots.

Proof Two — Outline View Shortcut Nitwits

Prior to Leopard the keyboard shortcut for expanding or contracting an outline view node was an arrow key with a masked option key. By 'masked' is meant it didn't matter if other modifier keys were pressed - as long as option was pressed it worked.

Starting with Leopard the shortcuts don't work if any other modifier key is pressed. This makes no sense and is counterproductive. There's no logic to it at all and it breaks expected behaviour going back perhaps ten years. Clearly the idiots who designed and wrote this code are full blown morons.

Proof Three — Table View Selection Nitwits

This used to be a brilliant part of OS X. A word of explanation is necessary.

Table view selections must naturally let users select multiple sequences of rows. Microsoft implement this and OS X always had - and OS X had a distinct advantage.

Doing this the Microsoft way assumes you've already selected one row; to select a new row you now hold down 'ctrl'. To move from this new selection to another row to select an entire sequence you hold down both 'shift' and 'ctrl'.

Sounds reasonable. But OS X had one up on Windows here. Starting over the OS X way again assumes you've already selected one row; to select a new row you hold down 'command'; to move to another selection you don't need 'ctrl' or 'command' - you merely hold down 'shift'!

Why? Because the table view already remembers the last row you clicked. It's bloody brilliant.

Here's how it worked on Tiger. And on Panther. And on 'Jag-wire'. And on Puma. And Alley Cat and all the rest. Expected behaviour.

First we fire up CLIX. It's a popular free download and it uses the table view. So it's an easy way to follow along.

We also open the '_leo.clix' CLIX command file available in the download but we run this under Tiger for starters.

Our objective is going to be to select all the 'DTrace' commands in the file (which are very cool). We start by selecting the first.

Now we select the next command in this category - 'Err Info' - by holding down 'command' when we select.

We now want to increase the selection to include the entire sequence from 'Err Info' to 'File By Proc'. We do this by holding down 'shift' and clicking on 'File By Proc'. It works.

And we can continue to do this as much as we want. And earlier selections will remain.

OK so now let's try this on the nitwit Leopard. Starting position is the same as before: we select the first DTrace command by simply clicking on it (no modifier keys). Note the screenshot is slightly larger - by one pixel on a side. This is because Leopard puts a fine black one pixel line around each window. It's good - but the beauty's only skin deep.

Here's the second step - we select the next command by holding down 'command' as we click. So far we haven't seen the nitwit effect.

And now we attempt to extend our selection from 'Err Info' to 'File By Proc'. Oops. We lost the first selection.

Try anything you want - you won't be able to do it. Try holding down 'ctrl' or 'option' or 'fn' - with or without 'shift' and you'll still be stuck in it. There is simply no way to extend table view selections with Leopard. And this is behaviour that has worked adequately - and consistently - since OS X was first released ten years ago.

For obvious reasons this is one of the most widely accepted proofs Apple hired on a litter of nitwits to complete Leopard.

Proof Four — The Mail Nitwits

Certainly people will never stop complaining about the Mail team - or pulling out their hair over all the creative ways these supposed 'software engineers' have made their lives more difficult (or even impossible). And a noticeable migration away from Apple's own mail client is already underway. Which should be enough of a clue. But here's another proof - 100% new for Leopard Mail.

Try this both with Tiger Mail and Leopard Mail to compare.

  1. Send a message to yourself.
  2. Wait for it to arrive (natch) and then redirect it. When the composition window comes up put nothing in the 'To:' field - put one of your webmail addresses in the 'Bcc:' field only.
  3. Send away.
  4. Stick around a while to make sure your redirected message - which wasn't addressed to you second time - doesn't come back.

On Tiger it won't come back - it's not bloody supposed to - but on Leopard it will. Even though you have no one at all specified in the 'To:' field.

Clearly this is another good proof Apple hired on a litter of nitwits to complete Leopard.

[It's also downright dangerous as can easily be imagined. Ed.]

Proof Five — The Temp File Nitwits

This last proof - for now - isn't about someone losing it. The general consensus is it's about someone who never had it.

Most people are aware Apple are going to ludicrous lengths to protect what's increasingly an unprotected system architecture. Considering this once was a 'rock solid foundation' that's no mean feat. But remember: this is 'Apple'.

Starting with Leopard temp files are all over the place. They use deliberately difficult paths. Not that these paths are a speed bump to more than Apple's nitwit engineers - what's ludicrous (and typical) is that these nitwits think this applies to everyone.

Couple this in wedded bliss with the sloppy job Apple have done on some of their 'standard' applications and you have a bit bucket junkyard threatening to become a compost heap.

Leopard Preview leaves an empty directory in these obscure locations for every image file you open.


Note these are not cache files - these are directories. Empty directories. They serve no function whatsoever.

They're just more proof Apple hired on a litter of nitwits to complete Leopard.

Proof Six — The Flippy Nitwits

Apple like to make things cute for their single digit user base. Source lists are one example of this. And certainly Microsoft have done similar things over the years. Many of their 'advanced' controls for Windows of today were introduced solely because their web browser Internet Explorer demanded them.

But these pervasive system 'enhancements' have a tendency to work on Windows whilst on OS X they tend to screw up.

Microsoft have a reputation for thinking in the 'bigger picture' when they introduce changes; Apple think only of their current application domain.

Nitwits. Here are 'source list' flippies for Tiger and Leopard side by side.

Check them closely. The Tiger variant (on the left) has a flippy (disclosure triangle) that's totally bigger in three directions. It's two pixels higher and at least two pixels wider. This is an object the user is supposed to click on. Why make the target more difficult to hit?

The text in the Tiger variant is correctly centred but not in the Leopard variant - where it's placed one pixel too high. This coupled with the anaemic flippy which increases the distance to the text and the user's impression is it just looks 'screwy'.

Failed ergonomics; ugly cosmetics; nitwits.

Proof Seven — The Networking Nitwits

Administrators are still pulling their hair out over this one. OS X is supposed to work in networks. Guess what? It doesn't. It's total toast. But that didn't stop the company from releasing a flawed product anyway. Yet two 'updates' down the line and you'd assume they now got this fixed. After all: you paid good money for what turned out to be a flawed and inoperable product and they have an obligation to fix it. But they're nitwits. They probably don't even understand the code they're looking at.

So how could they take code that already worked and ruin it? And not see something this important didn't work when they released it? And how can they remain incapable of fixing it through two significant updates?

The people spreading the rumours say they know. Apple hired on a litter of nitwits.


Those then are representative of the proofs being submitted that Apple hired on a litter of nitwits to complete Leopard. But did they hire on anyone at all? Or did they just use the nitwits they already had? Here is where the scholars disagree.

Those who claim Apple must have hired on nitwits point out that OS X code has never been this bad before; those who disagree say that OS X code has indeed been this bad before but things deteriorated gradually rather than all at once.

Those who refute the claim also point out that Steve Jobs is reputed to have nixed the idea to hire on nitwits early on, that Leopard was consequently delayed because of the iPhone, and that Apple's ISV support for Leopard came to a standstill during the rollout of the iPhone.

Both camps have cogent arguments to support their positions. About the only thing they agree on is that it's been a litter of nitwits screwing up some perfectly good code again.

The Windows Trap

OS X users have been finally caught in the 'Windows trap': they're looking forward to system updates not for new features but for fixes to bugs the company refuse to acknowledge.

OS X developers are caught in a similar trap for the first time - Windows never had a trap for developers. Things worked 'as designed'; 'expected behaviour' was consistent and 'expected'.

There are those who not only prefer Tiger over Leopard but also slip in a judgement that 'Tiger was OK'. Obviously these people are nitwits too. Tiger introduced bugs of a kind not previously seen in any major modern OS release - embarrassing cosmetic bugs too. And these bugs remained largely unfixed throughout the two and one half year life cycle of the system.

When Leopard was finally released Apple told their ISVs they weren't going to process any more bug reports for Tiger - they told them to upgrade to Leopard instead.

This proved to be a ruse. For not only weren't the Tiger bugs fixed but Leopard introduced a new batch of bugs of its own - according to rumours because Apple hired on a litter of nitwits.


It's one thing to have a brand new system under development. And to take it through its development and testing phase. And to be there and ready to get feedback from internal testing teams on things that need to be fixed.

It's quite another to have a system that's working properly out on the market, systematically ruin it, and categorically refuse to fix it over a period of several years.

Avie! Come home! All is forgiven!
 - Steve

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.