'This change was made as an optimisation'

Children with matches. Apple with operating systems.

Get It Try It

Something happened to NeXT's old FreeBSD a while back. Apple happened.

A bunch of programmers who were deep into PASCAL had to confront the new age thirty years after the fact. They were still writing programs in UPPER CASE like it was COBOL. They didn't know of C, much less Objective-C.

Objective-C was never the objection later on when Swift was created. C was the objection.

C requires understanding of what the fuck you're doing. C demands you know what you're doing. They didn't know much about that at One Wayward Loop. So transitions can take time. And be sabotaged along the way.

Ian Malcolm said it best when he warned of the dangers when people take over technology they don't understand. The NeXT OS was brilliant, built atop FreeBSD, which is a derivative of BSD Unix, which in turn is a derivative of the Bell Labs UNIX for which Messrs Thompson and Ritchie won a technology medal at the White House.

Unix permeates everything. It's used on most of the world's servers. IBM recently bought Red Hat Linux for billions. Unix is everywhere.

Bill Gates once had Unix. He bought a source code licence from Bell. He turned the code over to SCO. SCO made Xenix for him. Xenix didn't fare well.

Unix was felt in MS-DOS version 2.11. Backslashes replaced forward slashes and the Lattice C compiler was reworked to be more Unix-compatible. Of course this thinking didn't stretch down to making the PC system more secure, with ultimately 'ILOVEYOU' the result five months into the New Millennium.

And so the trickle of a Watership Apple had begun. Steve Jobs moved lock stock and barrel from Redwood City back to his hometown. The nerds there, however, were not ready. Avie Tevanian said, in resignation, that it might be better to just build a new operating system. What of course happened was total chaos. Yet Jobs kept the vessel on course somehow.

Steve Jobs is gone, the vestiges of a sane cohesive Windows-killer OS are almost gone as well. All that possibly remains are faint traces of common fucking sense. But now they seem to be going too.

The engineers at Apple aren't smarter than you. No matter they understand the bits and bytes, that doesn't mean they have common sense either individually or collectively. This site has ample examples of that. Nor are they necessarily capable of divining the bigger picture. In that they have proven to be woefully unequipped.

Piece after piece of the meticulously woven underbody that was the marriage of FreeBSD Unix and space-age user interface and application design by NeXT has eroded or been clumsily replaced, seemingly for no good reason, and with no explanation ever given. Stuff just disappears. Just like that.

There's been a problem with the system's toolbars for quite some time. This is but one example, of course, but it's a goddamned good example. A problem with the toolbars.

NeXT didn't need toolbars. NeXT had detachable menus. Had Apple kept these brilliant menus, they may never have needed to implement toolbars. But the toolbars remained as NeXT menu technology was trashed in what became a familiar occurrence.

Toolbars are a kind of 'speed bar' as Borland once called them before Windows or Microsoft had any such thing. (Microsoft had 'toolboxes' which needed retooling fast once Borland introduced their speed bars.)

The speed bar was conceived as a fast way to get at menu commands. (Once again, NeXT already had this with their detachable menus.) All a speed bar does is invoke menu commands.

But there's a subtle difference. Invoking a menu involves a whole slew of system events whilst the same thing for a toolbar doesn't happen. It's a click ('mouse down') followed by a release ('mouse up' over the same control area) and that's it. The corresponding sequence of events on a menu involves first invoking the menu as a whole. And this invocation must of needs require the client application be queried as to what menu items are to be enabled, disabled, or otherwise modified or enhanced according to the context at that precise moment in time.

(Menu items aren't seen until the user invokes the menu. Between the time the user invokes the menu and that fraction of a second later when the menu is displayed: that's when the system queries the application and gets the answers needed. Toolbars don't have that advantage - they're always on display.)

You click your Apple menu bar and a lot things happen. You don't see these things because they happen fast and because you're not supposed to see them either. Every last menu item on every menu and submenu has to be inspected. Every last one.

Note that when the above happens, the client application is in control. Through the magic of event-driven application architecture, it's the system itself calling the application, and not the other way around, something unheard of in the 'old days'. But today we have tables resident in binary images to show the system where to go.

So, at this point when the system asks a client (an application) about its menu items, the application is in control. The application - more correctly the document - will know what menu items will work and what ones won't. And so forth.

The client won't get the same opportunity for its toolbar. For the longest time this wasn't an issue, for the system would independently see that a toolbar was always updated ('validated') as need be.

That time ended, we now know in retrospect, quite a while back. More precisely, under the period of the 'Leopards'. To quote directly from the Apple notes:

In 10.6 and later toolbars no longer automatically validate for some events, including:

NSLeftMouseDragged, NSRightMouseDragged, NSOtherMouseDragged, NSMouseEntered, NSMouseExited, NSScrollWheel, NSCursorUpdate, NSKeyDown.

In addition, validation for NSKeyUp and NSFlagsChanged events is deferred with the timer restarting for every new deferrable event.

So a sequence of key events will not trigger any validation at all, until either a pause of .85 seconds, or an event other than NSKeyUp or NSFlagsChanged is processed.

This change was made as an optimisation.

Start from the beginning. Some events are no longer flagged. Left mouse dragged, right mouse dragged, other mouse dragged, mouse enter and exit, scroll wheel shenanigans, cursor updates, key down.

That's quite a lot. What can happen to a toolbar when things like that are going on? Obviously quite a lot. And wasn't it great that the system treated to visual feedback as those events took place? Of course it was. It was accepted, taken for granted. That's the way user interfaces are supposed to work.

The iteration in 'damage control' continues.

'In addition, validation for NSKeyUp and NSFlagsChanged events is deferred with the timer restarting for every new deferrable event.'

'Key up' is of course very important. It can mean, for example, that a toolbar button that's depressed must now return to its normal state. A change in flags can of course change everything. But you the user will no longer be clued in.

How bad is it?

'A sequence of key events will not trigger any validation at all until either a pause of .85 seconds or an event other than NSKeyUp or NSFlagsChanged is processed.'

0.85 seconds. Five sixths of a second. CPU time slices are measured in quanta, or multiples of milliseconds, or one-thousandths of a second. That's slow by today's standards but still Mario Andretti fast compared to five sixths of a second. A lot can happen in five sixths of a second.

Of course the fanboy approach is always a fanboy approach, one of the things that makes developing for this once-stellar platform so thankless. The fanboy approach is that they always know best at Apple even though history shows unequivocally that they fuck up on a biblical scale time and again.

But best of all is the explanation why this ungodly trashing of all that is sacred must take place.

'This change was made as an optimisation.'

That's it.

'This change was made as an optimisation.'

That's all you're ever going to hear. Apple will never tell you any more. Never. It's been an optimisation. An optimi-fucking-sation.

An optimisation of what? Of precisely fucking-what?

And they specifically state 'some events'. Where's the full list, Apple? Where's the full list of events you've scuppered and abandoned to shit? You'll never find that either.

Think about the size of it. Here you have a system that's worked great since the early 1990s and suddenly, some twenty years later, now on blisteringly fast hardware unreachable twenty years ago, they have so irretrievably fucked up the innards that they can't handle the event stream anymore? And they won't even tell people the full extent of what they've done?

'Mommy, I was playing with matches. There's been an accident. A bad one. I'm not about to tell you what burned to the ground either. Sorry, Mommy.'

Children with matches. Apple with operating systems.

You've obviously heard of us, otherwise you wouldn't be here.
We're known for telling the truth even if it's not in our interest.
We're now telling you to beware Apple's walled garden. Don't get locked in.
What you've seen so far may be only the beginning of something far far worse.
Download our Test Drive and at least check out our free Keymaster Solo.
That's the first step to regaining your freedom. See here.