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


Trade a bug fix for a feature.

Get It

Try It

As anyone who's been custodian for a large body of code knows: you hasten slowly. You don't implement change for the sake of change. And if you get any great ideas you sleep on them. Night after night. After a while the really good ideas will end up manifesting themselves as necessities. And those are the ones you want; the rest you throw away.

There are consultants who've worked at Microsoft who reveal how things instead work in a major commercial software company. It's literally impossible to get a team chief to allot you time to go back over old code and clean it. Those team chiefs are recognised and rewarded for all the cool ideas they come up with and implement. Nobody gives a flying fuck about cleaning code.

And guess what, Apple fans? Apple are a commercial company too and things there basically work the same way. Although in the brief history of OS X things haven't always been like that.

OS X 10.2 Jaguar was not a feature push - it was a basic effort to get a complete product out the door. And although adepts saw already in 10.1 that things were going to be OK a lot of innocent bystanders didn't. There was a lot of complaining and little patience. Considering the company were trying to create the perfect square circle they had to be given time. And considering this same challenge the results were pretty good indeed.

And right there one could stop and take assessment of the situation. Right there with 10.2 Jaguar Apple had the whole world beat. 10.2 was complete; all the pieces were in place; the system 'felt' complete and adequate; and in its roots it was - and still is - something the competition can never have.

A side bar. Why can't Microsoft have something like OS X? Why can't the Linux desktops? And it's admittedly staggering the Redmond company who ostensibly borrowed prototype Macs to serve up Multiplan for Apple but who were more interested in 'stealing the idea' managed to get it so wrong. Reminiscent of the spy counterspy game where the other side are deliberately fed flawed plans to screw them up. It's a wonder Microsoft could get things so wrong.

The essence of any graphical user interface is that it's either action oriented or object oriented. PARC had both back in the day. Most people went with the latter although there are still good arguments for the former. And a prerequisite condition for either is that application commands are separate from the document windows.

And Microsoft never got that. And the Linux desktop developers, raised on Windows, never saw anything else. So these FOSS GUIs today are just bad copies of Windows - with the same flaws.

Already in August 2002 Apple were ahead of the field. And this is not a head start Microsoft or the others can ever pick up either. To get the functionality inherent in OS X Microsoft would have to gut their entire GUI API and start from scratch again. They know it; those in the know outside Redmond know it; and they know we know it too. Twenty years ago they might possibly have done an about face and undone the dumb mistake they made in the early 1980s but now it's too late. And they're stuck and they know we know they know it.

From August 2002 to the present nearly six years later. 10.2.7 was a pinnacle; already with the next 10.2.8 release something was wrong. 10.2.8 was pulled within 24 hours of release. It's good they caught the error but it was unsettling because nothing like that had ever happened before with OS X. An ominous cloud on the horizon.

Today the big move is to 64-bit, Leopard, and beyond. It's certainly a big move. Will it work?

For it to work the API has to work for developers. OS X like no other system has a symbiosis between developer and user. There's never been a system works so fast to create quality code in a fraction of the time normally needed. Most often estimated at about 20% of the time used on other platforms. But with Leopard there are many serious issues and some of them date back to Tiger and even Panther (but not to Jaguar). For the system to gain widespread acceptance - to become a 'gorilla' of a platform for universal development - these 'idiosyncrasies' have to be rolled back.

Mail: Jaguar Mail was OK. At least it had no bugs to speak of. It also had a clean design. And by design is not meant how the controls are organised on screen but rather the way code is used under the bonnet. Jaguar Mail had a really cool feature too: when you deleted a message the text faded away. Somehow that got lost over the years. Now might be a good time to roll it back.

Today Mail is a mess. There are new features all over the place but most users would gladly trade an app that works as advertised without bugs for a new feature or two. You can't put off taking care of the bugs: if you put it off until tomorrow you'll put it off until next week, next month, next year. Which coincidentally is what's happened.

Leopard Mail: save a draft in plain text, open it again: you're back to rich text. First time every time.

Mail and services: first time if there's something to do it works; second time if there's nothing to do it wipes out your selected text; third time - even though no text is any longer selected - it still responds? And now says you should contact your vendor? Hello?

Roll it back. Services worked great under Jaguar / Panther. All those stupid messages people get from Windows users that can't wrap text lines and make email look like a lost cause - people have to be able to do something about it. And OS X does have that capability. Except since 29 April 2005 it's been broken.

Leopard Mail has addressed the issue - but it's amazing. For even though behaviour has changed it's still not fixed. Meaning those who looked at the code didn't do more than read the back of the box. And with Leopard things took another turn for the worse: someone went into the AppKit services code and broke that code too. And 10.5.2 didn't fix it either. It's still broken - almost three years down the line. It still doesn't work as advertised again. Three years later - something of a world record even (or especially) in commercial software.

Leopard Interface Builder: it can't satisfactorily remember if changes have been made or not. Again: it used to. Before this release there were no issues whatsoever. Now it nags all the time. Roll it back.

Leopard Safari: it still crashes irrevocably and unconditionally on 'Inspect Element'. First time every time. BAM. It's gone. 10.5.2 and it still crashes. World's best browser crashes and burns right out of the starting gate. Every time.

Inspect Element is a new feature and it crashes in its C++ code. But fixing this bug shouldn't be too difficult at all. All that's really needed in the short run is a 'band-aid' and looking at the stack trace it's pretty obvious how easy this would be. Three versions for Leopard already and the app still isn't seaworthy.

Leopard Safari and services: similar to what happens with Mail. First time it works fine; second time it works fine; but if there's nothing to change it removes all text.

But that's only when you're legally supposed to be able to change something. What happens when you're not supposed to?

It's obvious Safari's rendering control inherits through NSResponder. But what the Safari team have evidently never noticed (or arrogantly ignored) is the fact this NSResponder code interacts with the AppKit services engine.

NSResponder namely responds to the following message.

-(id)[NSResponder validRequestorForSendType:(NSString *)sendType returnType:(NSString *)returnType];

The documentation explains what's going on.


A string identifying the send type of pasteboard data. May be an empty string (see discussion).

A string identifying the return type of pasteboard data. May be an empty string (see discussion).

Return Value

If the receiver can place data of sendType on the pasteboard and receive data of returnType, it should return self; otherwise it should return either [super validRequestorForSendType:returnType:] or [[self nextResponder] validRequestorForSendType:returnType:], which allows an object higher up in the responder chain to have an opportunity to handle the message.


With each event, and for each service in the Services menu, the application object sends this message up the responder chain with the send and return type for the service being checked. This method is therefore invoked many times per event. The default implementation simply forwards this message to the next responder, ultimately returning nil.

Either sendType or returnType - but not both - may be empty. If sendType is empty, the service doesn't require input from the application requesting the service. If returnType is empty, the service doesn't return data.


Available in Mac OS X v10.0 and later.

See Also
  • registerServicesMenuSendTypes:returnTypes: (NSApplication)
  • writeSelectionToPasteboard:types: (NSServicesRequests protocol)
  • readSelectionFromPasteboard: (NSServicesRequests protocol)

Read-only pages are to return nil for a non-empty returnType; Safari's web pages - which are supposed to be read-only - do not. Most likely because the Safari team aren't aware NSResponder is communicating with the AppKit's services mechanism.

It's therefore possible to use any text service obtainable anywhere at all and deface any web page anywhere with Safari. Not good.

This isn't a matter of rolling something back; what the Safari team need to do - and it's an incredibly simple fix - is to override validRequestorForSendType:returnType: to return nil on a query with a non-empty returnType.

-(id)validRequestorForSendType:(NSString *)sendType returnType:(NSString *)returnType {
    return (!returnType || ![returnType length])? self: nil;

That's all they'd need.

launchctl singleuser: it still works. You can still shit all over your login session and lose all your work and data through this incredible gaffe. It still works in 10.5.2. Roll it back.

Address Book: it still can't sort. Not with 10.5.2 either. Roll it back.

Mail still trashes the Drafts folder. Even in 10.5.2. For some weird reason the new programmers decided that if the Drafts folder is empty on startup there's no reason to display it. But guess what? There's no way for the user to display it either. Yet it's still possible to move a message to the Drafts folder even though you can't see it - and can't get at it either. Your message is moved to the Drafts folder - and disappears. Where did it go? It's there all right - check on disk. But you can't make it appear unless you hack your way through a workaround. This is the epitome of bad and 'unvetted' design like few other examples and it's been there since Tiger and remains in Leopard all the way through 10.5.2. You'd think someone has to wake up sooner or later but you might be wrong. This is a gaffe almost three years old already.

Screen rendering issues: multiple applications still leave 'screen remnants': torn off scroll bars, munged menu bars, etc. Things here took a turn for the worse with Tiger; at first the reports seemed unbelievable; but they were very real all right. The thought prospective switchers wander into an Apple store and see this is really frightening. Again the hope was this would be fixed in Leopard. It's not. Not even in 10.5.2.

MDItemMarkAsUsedWithPathAndCatInfo: might still be crashing apps when there's a communication breakdown with the launch services. Hard to tell as most ISVs have had to put in band-aid code to protect against this and legacy systems are still going to need it. At any rate there's been no word from Apple it's been fixed - only that it's been acknowledged as a bug (and a serious one at that).

Preview: Tiger Preview was really cute. You could rotate or flip images - only Preview was the only app that could see the difference. In all other apps - Safari, Mail, et al - the images appeared unchanged. Now with Leopard there's a feature added to the 'save as' sheet that seems to be basically saying 'do you want your image to look the same in other apps as well?' Staggering.

Safari cookies: Safari gives you three cookie options: 'always', 'never', and 'only from sites you navigate to'. But this third option has never held. No word if this will ever be fixed. And note: a cookie that begins with a dot (.) is not going to be a site you navigated to. Period.

Safari used to download 'into thin air'. In Tiger you could delete a download in progress and Safari wouldn't notice a thing; today it uses an extreme approach with folders and embedded files and winds things up by moving the download up a notch. So if the download is somehow deleted Safari will notice. But it won't stop the download if the file no longer exists.

Window levels: it's possible to tab inside a 'sheet' and actually be sent to another application instead of the next control. This was one of a number of issues that were supposed to be fixed with Leopard. As of 10.5.2 it's not.

There are more examples of bugs that have to be 'rolled back'; there are countless lists on the net already today of features that have suddenly been broken with 10.5.2 Leopard. Instead of forging ahead and trying out new cool ideas Apple should try to empty their bug reporter inboxes and make Leopard the stable and reliable system it needs to be.

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