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

People to Meet (1)

It's a long line.

Get It

Try It

Leoptard's the new V*STA, says Oliver Rist, and it's pissing him off.

Stand in line, dude.

Rist's has five objections; they're basically spot on. He misses a couple of points but that's no big deal. The five things he doesn't like are the waiting for point updates until things are good enough, needless graphics 'glitz', pointless UI 'fixes', nuked networking, and 'bundled apps as new features that suck'.

One thing in particular Rist takes up in the video clip for this article strikes a chord. 'I'd like to meet the UI guy who thought that was better than Tiger - I don't get that', he says referring to what he calls the 'cornflower blue baby fuzzy toy you can't see in the mirror' sitting on the dock under active applications.

Actually there are a lot of people to meet.


We'd like to meet Dave Hyatt. We really would. We'd like to ask him who's been keeping him muzzled all these years and why he can't come clean about bugs he's had that hosed entire systems.

And we'd like to ask him about how we or anyone can surf to Apple's website, apply a text service, and completely ruin any page.

And we'd remind him the 'bug' is several months old at the least. And we'd like to ask him why he hasn't fixed it.

Rendering in Safari - as almost everywhere in OS X - is based on NSText, a monster of a sophisticated text engine. Almost unparalleled. You can know NSText and Cocoa are in there because of what Safari does.

But an ordinary NSText view (NSTextView or NSTextField) is editable and a rendered web page is not.

The way services work is as follows. The Cocoa AppKit checks the services menu items. Each menu item has a specification for incoming and outgoing traffic. That's specified in the Info.plist itself. The AppKit then goes and queries the current target if it can handle a service.

The only way text services can work is if the target accepts data back. Which is what NSText buried inside Safari is doing. Because unknown to Hyatt your web pages are editable. Right there. In place. No you can't edit them yourself but program code can.

Hyatt gets the query from the AppKit. 'Do you accept text back?' Hyatt's of course supposed to answer 'no'. But he doesn't - he probably doesn't even know about this. He doesn't override the default answer which in this case is wrong. His Safari pages answer back 'yes - give us the text!'

Now it goes even deeper. Because at this point the text is in fact sent back. When it shouldn't have been. And now Hyatt's Safari page is going to act on that text change - again most likely without Hyatt having a bleating clue it's going on.

But if you wanted to do a 'cheap 'n' easy' fix you wouldn't need to remove/override that code. No - all you'd really need to do is answer 'no' instead of 'yes' to the first question from the AppKit.

Let's take this really slow: on a single line of code Hyatt needs to change a single value - a boolean '1' - to another value - a boolean '0'. That's it. It probably takes typing a single character. Find the incorrect '1' or 'YES', select it, and type a '0' or 'NO' over it. Save the file and rebuild Safari.

They can't do that. The bug's been there for them to see; they should have caught it themselves; it's been months; they don't fix it. So it'd be nice to meet that guy all right.

[Hyatt's blooper actually goes way deeper. Once the 'read only' page is modified up the 'undo' and 'redo' menu items are enabled because the underlying code flags the changes and validates the menu items. This is another thing Hyatt has no clue about.]


There's someone else we'd like to meet. And have Dave Hyatt meet. And vice versa.

Is it the guy with the dog? Who knows. That picture isn't packaged anymore. And could it really be the same guy who originally wrote the program? That's hard to believe because it used to be a good program. How could the same guy go in and rip apart this code and make something so terrible?

And it wasn't really his own code to begin with of course. The code came from another company. And he only had to have the good sense to not try to 'improve' it. And for the longest time he resisted that temptation and things were OK. But he did do the right thing. For the longest time.

So it's easier to see this next person as someone aside from the original author. Of Apple Mail of course. And there are a lot of questions to ask him.

Let's start.

OK. So back in the good old days five years ago this program actually worked. It wasn't an aircraft carrier but it had almost literally no bugs. It had no visual quirks whatsoever. It. Just. Worked. End of story.

It had a drawer and drawers were difficult to implement. IB keeps assuming things about sizes and you work separately with the 'view' inside the drawer. Etc. So someone decided 'gut the drawer'.

The drawer was cool not only because you could retract it but because you could decide which side it came out on. Drawers have a setting for 'default edge': up, down, left, right. But they influence this themselves at runtime depending on where screen real estate is available.

If a drawer is supposed to come out on the left but the parent window is flush against the left of the screen it'll have to come out on the right. This is no big deal. Once you get the drawer working right you don't have to worry about it again. So for example introducing a setting for 'change default edge' would be ridiculous.

But when you start the brain dead whiz bang replacement code to sort of informally 'extend' a window to make room for the mailboxes - and remember this is no new code class in the world of object orientation - THIS IS A BLOODY HACK - you can't choose sides anymore.

So right there you made a crappy decision.

Populating the toolbars with jelly babies don't matter much. Not really. It's something you can roll with. But what does matter - what you can't roll with - is the fact all this has to run outside the class code in Cocoa for toolbars.

It's just a bad decision.

Then there's the actual composition window itself. And seriously: have even Microsoft ever done something so terrible? NO THEY HAVE NOT.

The old Mail from the good old days had this supercool message deletion hack which made text fade away before the message was moved to the trash or otherwise dispensed with. This was a simple two or three code line loop and it didn't hurt anyone and it looked really good. The composition window was of course based on NSText as so much in this system and that was good. And the program was stable.

And then someone decided to 'improve' it. This was terrible. For in the process a lot of things were ripped apart. And they were not put together again correctly. Some of them have been fixed in Leopard but most have not been fixed.

You could see the writing on the wall already in Panther when the app took on a decidedly 'fartsy' feel but it was first Tiger when things really went down the drain.

Inside any editing area you always have its editing rectangle. This rectangle is always set in from the edges of the control. If you have Safari then get the source to this page and select all and see. You'll see the text all selected in blue and then you'll see a white border around it before you get to the edges of the window. The blue part is the 'editing rectangle'.

But this editing rectangle is also the 'clipping' rectangle. When you overwrite anything on a computer screen you're not literally erasing first - you're covering it with a default colour or background pattern.

You're not allowed to write on anyone else's controls or windows and if you try your efforts will be 'clipped' off - you'll only end up affecting your own control or window anyway.

But what happens if you calculate your clipping rectangle too small instead?

Easy. When you calculate your clipping rectangle too small your erase operations won't clear everything away. YOU'LL LEAVE DATA REMNANTS.

So if you're starting a reply in Tiger Mail and you suddenly maximise the window you'll see the shit from the bottom two lines or so just 'get lost' on there - and nothing you do can make it go away. BECAUSE IT'S OUTSIDE THE EDITING RECTANGLE.

Now of course you'd wonder a number of things at this juncture.

- Why did they gut NSText - and then try to put it together again?
- What's so bloody good about the new design even if it works?
- Don't these guys even eat their own dogfood?
- How can you have a glaring GUI blooper like this in showrooms for years?
- How many thousands of times was this reported as a bug?
- What was so important they could never fix this?
- Do they want people to see this and conclude Apple are a bunch of clumsy amateurs?

And so forth. Naturally this 'programmer' is someone you gotta meet. But it does deeper still. And it ties in with Hyatt's bloopers as cited above.

Two of the most grateful things with Jaguar/Panther Mail was that 1) it just worked; and 2) you could use text services to clean up mail coming from people using 'that other operating system'. You know the drill: lots of '>'s all over the place, message text a real mess. They live in a Neanderthal age. Text breaks - it doesn't wrap or flow.

Obviously you need something to deal with this - or go on a Windows user genocide rampage - and we have it. It's a text service called 'Tidy Up Quote'. You can set any keyboard shortcut you want but we suggest shift-command-double quote (⇧⌘"). It's really easy.

And the code is really good. You just select the crappy Microsoft text and hit ⇧⌘" and WHOOSH - it's taken care of. And it works everywhere. Not in one particular program. IT'S A SERVICE. IT WORKS EVERYWHERE.

Everywhere except in the Ricki Lake makeover of Mail for Tiger that is.

Now it's important to understand that to get this working in Mail for Tiger the programmers DIDN'T HAVE TO DO ANYTHING - THEY JUST HAD TO NOT SCREW ANYTHING UP.

Getting this kind of functionality in a composition window in Mail doesn't take extra code - THE CODE'S ALREADY BEEN WRITTEN. IT'S IN THE COCOA CLASSES.

[Yes this is what's so bloody brilliant about object orientation in case you didn't get it. Ed.]

There's a whole lot of interaction between applications and the AppKit in this regard as outlined above but most of the time you don't see it. It's already been written.

For the provider it looks like this. The provider's given a call with a pointer to the special services pasteboard. [NeXTSTEP/Cocoa has several pasteboards and more can be defined at any time and this special pasteboard is at any rate not the so called 'general' pasteboard used for copying and pasting.] It's also given a pointer to a character string which defines the 'request' of the client application.

People totally unfamiliar with this might be scratching their heads. Pasteboards (clipboards) aren't just (primarily) for copying and pasting. Basically they represent a memory area where applications can exchange data without poking into each other's address spaces.

On Cocoa the AppKit takes care of that. You ask the AppKit to put data on a pasteboard. The AppKit can see these pasteboards - you can't. Not directly.

So when the provider gets a request - as outlined above - it acts on it AND USES THE SAME PASTEBOARD POINTER TO PUT THE MODIFIED DATA BACK.

The provider doesn't know the name of that mystery pasteboard. It can't access it otherwise.

On the client side in Mail something similar happens. But it normally happens at a very low level deep in the innards of the NSText code. Something at a level you by strict definition don't want to muck with. You. Do. Not. Have. Permission. To. Muck. With. It.

After the client (Mail) gets a general query about 'do you want text' (to which it by default answers 'yes please') it's sent a new call with a pointer to the same pasteboard the provider just got through using.

And here's where Apple Mail for Tiger started going wrong in April of 2005 - and is still wrong. For a reason only the 'programmer' responsible - and likely only under duress - will ever be able to explain he doesn't just take the pointer sent him but actually goes out and makes one of his own.


NSPasteboard *pb = [NSPasteboard generalPasteboard];

And again: that's what you don't do. You just take the pointer given you and wash it down with a hot cup of shut the F up.

And what happens if you use the wrong pointer to the wrong pasteboard? Guess. Instead of getting the modified text back (which you explicitly requested) you get whatever was left on the 'general' copy and paste pasteboard since last use.

And again: this took no coding in earlier versions of the program. IT WAS ALREADY THERE. In the AppKit. In NSText. It. Just. Worked.

So wouldn't it be cool if the programmer responsible for the demise of Apple Mail could get together and compare notes with the person responsible for the demise of the OS X web browser? They might come up with something.

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