But after Apple released 10.4.11, I started receiving crash reports at an accelerated pace. The log is the same in every instance, and culminates in what appears to be a threaded NSURLConnection caching operation:

-[NSURLConnection(NSURLConnectionInternal)
	_didFinishReturnCachedResponse:]
-[NSHTTPURLProtocol startLoading]
-[NSURLConnection(NSURLConnectionInternal)
	_performOriginLoad]

Now it so happens that WebKit is the one crashing in many of these cases, but I suspect the problem is more widespread than that. In any case, the problem is definitely more widespread than just MarsEdit. Searching Google reveals a number of similar results, from a variety of applications, including Apple’s own.

If you’re a developer and your application uses WebKit or NSURLConnection, chances are you’ve noticed an increase in crash reports, too. Always on 10.4.11, always involving NSURLConnection. If you’re a user running 10.4.11, chances are you’ve noticed that network-enabled applications seem to be a bit more flakey and crash-prone.

The fact that the bug seems to be fixed in Leopard makes me think that this is a bug whose source was identified and fixed. Now the question is, will Apple ever ship a 10.4.12 containing a fix? Or will those users be stuck in crash-ville forever?

Apple needs to get this fixed. For these poor 10.4.11 users who got stuck with a buggy URL loader, and for us poor developers who have to gently explain to them that it’s out of our control. I have to assume there’s already a bug reported against this, but better safe than sorry, I wrote up another one: Radar #5704773.

So why I am I writing this blog entry? Because I want other developers who read my blog or who find it by Google search to know that they’re not crazy. And I want users who run into this crash to please remember to send the crash report to Apple. They need to know that this is a serious issue that is impacting you and the apps you use.

Inspiration

Before anything else, you’ve got to be inspired to change. That might sound fluffy, but it’s absolutely critical. If you’re not convinced that your UI needs an overhaul, then you might as well forget it. You can rub sticks together for an eternity, but if you’re not cold, you’ll never start a fire. You have got to be dissatisfied with something before you can make it better. For reference, this is what I was becoming increasingly dissatisfied with before embarking on this journey:

I was pretty happy with FlexTime 1.0 when I released it. It did the job. I had never designed toolbar icons before, so I felt pretty good about the matte blue stencils I came up with using NodeBox. Hey, that was a nice piece of work for a newbie UI designer who is just trying to get something out the door. But it quickly started to grate on me. The interface was not suited to evolution. The inequities between the square corners of the list view and the round corners of the details box made it hard to embed anything more complicated than the few standard controls I have in there now. I was trapped my 1.0 interface, but I couldn’t figure out what needed to be done to fix it.

What followed was basically a month or more of working on anything but the interface. I couldn’t bear it. I found myself frustrated whenever I looked at it, because I knew something drastic had to change. But what? I worried I might have to scrap the whole thing and start from scratch.

Then I was sitting in Chicago at C4, listening to John Gruber talk about the “death of the HIG.” He brought up Brent Simmons, using his NetNewsWire as an example of somebody who had made a big impact by stepping outside the HIG guidelines. What Brent had done was an app that had broken with traditional HIG guidelines by eliminating the margins around the main views in his window. That’s when it struck me: “I’ve got too many margins.” I immediately envisioned FlexTime with its list view and details pane flush against the left and right edges of the window. That was it. I just realized that was where I’d start, and left it in my head to sink in. I spent the rest of the weekend on not really thinking about it.

Losing The Margins

When I got home, I didn’t waste much time getting to work on this. I busted open Interface Builder and started moving stuff around. About the only “gotcha” with this exercise is getting the UI to look good flush against the edge. A trick I discovered (and recently saw repeated by Brent Simmons on a mailing list) is that many views, table view included, will look best if its border is hidden off the edge of the screen. To accomplish this, you can simply set the x origin of the view to -1. This is a good trick to keep in your back pocket for a variety of finishing touch-ups.

I realized quickly that zero-margins on the left and right sides made the text labels and associated whitespace above the respective sections look stupid. Gasp! Could I just take those labels out? But the user will be lost without them! The main instructiveness of those labels was to tell the user that the list on the left was an “Activity List.” I discovered that by changing the main column’s label from “Name” to “Activity Name,” I could get this point across well enough without using a sledgehammer to drive it home.

A Touch Of Polish

I also decided pretty early on that the streamlined look might go well with one of the “polished metal” looks from Apple’s suite of applications. I ended up using PolishedWindow, which masquerades as “TunesWindow” on Matt Gemmell’s web site. He basically put together an NSWindow subclass that draws its background with a bunch of images to match Apple’s iTunes-ish windows. This was a real simple change to integrate. If I get time I might try to improve the code by getting it to use computed gradients instead of images. I feel like the code could probably be a bit faster during resizes. But for a quick fix this was a real champ.

Well shoot howdy, that looks pretty good. It’s such an improvement to my eye that I was frankly about ready to call it a day and ship it. But once you start moving, the inertia of change pulls you along until it’s ready to slow down. You set out to change one thing, and can’t estimate how many changes you’ll ultimately end up making. I showed the screenshot to a few friends, and what do you know, they found plenty to complain about. The icons looks out of place. There is no dividing ridge between the content and the top/bottom sections. The selection of the table should be a gradient. What’s that funny blank column at the end of your table? Pinstripe grey looks wrong in a polished window. The problem with having smart friends is they always have an opinion. You’ve got to learn to dismiss some feedback as a matter of taste. People feel passionately about Coke and Pepsi, but what do you know, they’re both successes. But often the things that rankle one person are going to upset a lot of others, too. So I take early feedback seriously. I might argue with a person, if only to make them justify why their suggestion is right. When the feathers have settled, usually it turns out that they were right, and I’m wrong. So I fix it.

Pinstripes, Ridges, and Gradients

It’s hard to see the pinstriping in the above screenshot, but trust me, it’s there. It’s not so bad, because it sort of blends visually to a light grey, but it really bothered some friends who saw it as out of place in the polished window. I also decided to add a gradient shine to the table view selection, and some defining “ridges” between the main content and the toolbar on top, and bottom section on the bottom.

The ridges are probably the most embarrassing of the three solutions, so I’ll start with them. I don’t know what the heck I’m doing. I’m a frickin’ professional, but I’m also an amateur. We all are. Professionals are just amateurs who know it’s not worth faking like you know something you don’t. In all seriousness, one of the things that makes me a professional is my ability to prioritize “working code” over “correct code.” I look at those ridges, as they appear in something like iTunes, and all manner of possible solutions spring to mind. I can rewrite the window subclass to draw the ridges as part of the background. Or I could devise a special “polished window content box” that draws the desired outline on the top and bottom edges. But the simplest solution at the time seemed to be popping arbitrarily colored “divider lines” into the UI at the appropriate spots.

I for one have always taken the “divider” for granted. It’s such a simple UI element. Usually you drag it in from Interface Builder and let it sit there undisturbed for the life of your product. But I want a colored divider line. In fact, I want four of them, positioned just right so they look like fancy iTunes ridges. In Cocoa, it turns out that divider lines are a very special variant of NSBox! Who knew? So I set about subclassing NSBox to provide colored divider lines. RSColoredBox should really be called RSColoredDivider or something that is more honest about the presumptions the code makes. I don’t think it will make a very good colored box, per se. I thought it would at first, but it turns out that the way Cocoa and IB plop down “divider boxes”, they have boundaries that lie. Divider boxes are of a special variant and are actually much taller or wider than you’d assume. Anyway, use that code if you want a colored line in your interface. Just drag a divider in from IB, set its custom class to “RSColoredBox,” and then call “setBoxBorderColor” on the line at awakeFromNib time. Cheap hacks, baby. Take it or leave it.

Getting rid of the pinstripes in my NSTabView is also not quite as simple as one might guess. This is one of those moments where you think “why doesn’t NSTabView have a backgroundColor attribute?!” The options for NSBox are that you can have it draw nothing, or draw pinstripes. Tough love. The cheapest way I could find to work around this deficiency was to subclass NSTabView and take over the drawing mechanism. Instead of drawing pinstripes, which is all the parent class does, I’ll just fill a rect. Again, this isn’t a very robust class – it only works when the tab view is … tabless. C’est la vie. RSColorBackgroundTabView is available for your perusal.

Finally, the gradient table view. This is one of those things that can be done right, or any of a million varieties of wrong. I was lucky to discover that Wil Shipley had written, during his time at Omni, a perfectly reasonable gradient-highlighting table view. You’ll need to snag the code from OmniAppKit, where it’s provided with the same license as everything else in that fine package. The things Shipley’s code does right are that he computes the gradient programatically, and he obeys the user’s highlight color. These two qualities made the code an easy sell for me.

Pie In The Sky

The “empty column” in the screenshot above corresponds to the animated pie-chart progress that is displayed when a user is running a FlexTime routine. It becomes obvious what it is, as soon as you start running something. But I had to agree with my critics, a blank column header is kind of a cop-out.

My first thought was to simply reuse the excellent pie chart cell I use for the table content, which is based on Jon Wight’s Toxic Progress Indicator. I allocated one, configured it appropriately, and then “setHeaderCell:” on the NSTableColumn. This sorta kinda worked, but there were major drawbacks. First, the drawing of the pie chart at that size revealed aliasing problems that didn’t really look polished. I’d have to edit the code to improve the compositing over the background, or something. Second, when you take over responsibility as a header cell, you take over all responsibility. You’ve got to draw that cute polished background, in addition to the content. Now I’m sure I could have gotten this all to work, by employing the existing default table header cell to do some of the heavy lifting, or by subclassing it. But I heard a little voice in my head screaming “overengineering!” so I took a step back. Paul Kim pointed out that I could simply “setImage:” on the existing header cell, and it would draw it for me, nicely composited over the polished background. Why go to the trouble of dynamically generating a pie chart image when one put together in PhotoShop will look just as good and be 100% predictable?

The image looks pretty good in the table header, but what’s that ugly crud on the edge? Why is it that I can’t spend more than 15 minutes at a computer without finding a bug in somebody else’s code? It’s the curse of the tester. I started my career in Quality Assurance and I’m doomed now to forever discover all the bugs. What’s going on here? It’s a bug in NSScrollView, or NSTableView. When a table view suddenly acquires a vertical slider, it causes the existing table headers to scrunch up and make room. In the space formerly occupied by the right-most table header, a special view is inserted called the “corner view.” This view is responsible, normally, for just drawing an empty background. After some debugging I discovered that when an NSTableView acquires a scroll bar, the cornerView is made visible, but not asked to redraw. That means whatever was on the screen before it appeared just gets left there. Usually you get lucky, because what was there is blank table header background. Most table headers are left-aligned (only on left-to-right language systems?), and the text rarely reaches the far right edge of the table. Leave it to me to find the exception.

When I run into a bug like this, I like to confirm as quickly and definitively as I can that it’s not my problem. If I take a simple project, like Apple’s “OutlineView” developer example, and cause it to have text that runs up against the right edge, then I see the same bug:

(Radar #4818521)

A workaround is to aggressively listen for table column resizes, and force the corner view to redraw itself whenever this happens:

- (void)tableViewColumnDidResize:(NSNotification *)notification
{
   // Force the tableview's cornerview to redraw.
   [[oTableView cornerView] setNeedsDisplay:YES];
}

Clickable Text

One of the biggest payoffs of this redesign was that it suddenly made the most ambitious part of my evolving UI a lot more palatable. I heard loud and clear that people were asking for large timer feedback while a routine was running, but I was having a hard time integrating it into the FlexTime UI. While the timers are not perfect, I do think they fit in a lot better in the margin-free context of FlexTime 1.1.

It’s worth talking a little bit about that custom UI. I wanted to satisfy two major design requirements:

1. The time display should be large and easy to read.
2. The time display should be easy to configure and disable.

I decided on large clickable displays. The simplicity of changing a configuration by simply clicking it is hard to argue with. Don’t like what you see? Click it and see if it gets better. I haven’t had a lot of feedback yet, but I suspect this “implicit configuration” is probably much preferable to a preferences panel or something where the options are painfully selected from a list of radio buttons.

Now if you’re like me and tend to stick with standard UI pieces, you’re probably wondering how I put that little piece of work together. One reasonable approach would be to design a custom NSView subclass and handle all the hit testing and state changes in there. In fact, that’s probably a smarter way to go about things, but for whatever reason I tended towards the “design entirely in IB” path this time around. The “custom view” in this case is an elaborate contraption formed out of NSTabViews, bindings, and clickable NSTextFields. When you click an NSTextField, it changes the “view mode” for the display, which is a property of the document. An NSTabView contains the three view modes, and is bound by its “selectedIndex” binding directly to the viewing mode (conveniently an enum that matches the NSTabView indices). The text fields for the time displays are bound directly to “time remaining” or “time elapsed” values, which are NSTimeInterval values (double precision seconds). To present the clock-style format I attach a value transormer, RSTimeIntervalToClockStyleFormat, which turns the seconds into a pretty string as shown.

If you imitate this approach, you’ll soon learn that NSTextField is not clickable by default. But it is an NSActionCell. It has these qualities but normally only uses them in an editable context, where the target/action paradigm is applied when the value changes or editing ends. To extend the functionality to mouse clicks, simply subclass NSTextField (mine is RSClickableTextField) and override mouseDown:

- (void)mouseDown:(NSEvent *)theEvent
{
   [self sendAction:[[self cell] action] to:[[self cell] target]];
}

Buttons 2.0

By this time, things are really starting to look good. My margins are gone. I’ve got my gradient. My light grey background. My polish. My pie chart header cell. Up to this point people have been screaming about the buttons, but I’ve been laughing it off. Haha! Maybe for 1.2. I just couldn’t muster the psychic energy to tackle such a big part of the UI. But the incongruence of those flat buttons was really starting to gnaw at me. I decided to take a stab at improving at least the color, and it quickly turned into a day-long obsession.

While the original buttons were entirely built from NodeBox, I decided I needed to add some lighting effects and anti-aliasing that were simply not feasible in NodeBox. So I started with the NodeBox generated images, but set up a PhotoShop document to apply various manipulations to the images by filter layers, semi-transparent gradients, etc. It was a learning experience, but I’m pretty happy with the results.

As you can imagine there was a lot of tweaking and testing in this process, and one of the best things to come of it was my decision to build a “Generate Toolbar Icons” script. I organized my PhotoShop document in such a way that all of the various toolbar icons are in one document, so to save a particular icon you just hide all the other buttons’ layers. This is cool because all the effects layers and gradients are consistent and can be changed in one place, where you’ll be sure they apply to all of the buttons.

Hiding and showing the layers would be tedious to do by hand, but PhotoShop’s “layer set” concept makes it easy to script. By putting all the toolbar buttons in a layer set called “Buttons,” I am able to easily hide all of them:

	set buttonSet to layer set "Buttons" of myDoc
	set visible of layers of buttonSet to false

Then I can iterate through all the layers in that layer set, setting the visibility of the layer to true, exporting a copy of the image, and setting the visibility back to false:

repeat with layerIndex from 1 to count of layers of buttonSet
	set thisLayer to layer layerIndex of buttonSet
	set visible of thisLayer to true
	set outputName to outputPathRoot & name of thisLayer & ".png"
	save myDoc in outputName as PNG with copying
	set visible of thisLayer to false
end repeat

If you’ve used PhotoShop to “Save As,” you know how painful it is to constantly go through the options dialogs. AppleScript makes exporting even one image easier, but with my script I can easily regenerate all nine icons and spit them out directly into the appropriate source directory.

Wrapping Up

The only downer to doing a GUI redesign is that all of your pictorial documentation becomes instantly obsolete. After the relatively fun work of designing the graphics and tweaking the layout, I realized I’d have to redo all of my Help Book graphics, and the screenshots for download sites and my web page. The lesson I learned from this is that to whatever extent possible, you should keep the “art” separate from the notation. For instance in my documentation I include a screenshot with various annotations made upon it:

In 1.0, I foolishly generated this graphic in Pages or something, and saved it as a bitmap image. Dumb, dumb, Daniel. From here on out I’ll be conscientious about saving with layers and keeping the application UI “swappable” with a new graphic, where only minor adjustments might need to be made to the overlays.

That’s the story of how FlexTime got its HIG on. Hope you enjoyed it picked up a few new tricks along the way.

One of the aspects of Mac OS X programming that can really frustrate traditional Mac OS programmers is the lack of error reporting from many APIs. While traditional Carbon APIs tend to return numeric failure codes when something goes wrong, it’s not unusual for CoreFoundation and related APIs to simply return NULL. What’s the developer to do in this case? The usual argument is that NULL is returned only from functions where a more specific error would not help the programmer convey meaningful information to the user. In other words, if it returns NULL when you don’t expect it to, your computer is either melting down, or you’ve got some debugging to do. Regardless of the validity of this argument, it can be infuriating to look at code that seems perfectly correct, and be clueless as to why it is failing.

I was chatting with Jonathan Wight when he shared his frustration with the CGBitmapContextCreate function. He was in the midst of debugging just one of these mind-boggling NULL returns. All the parameters looked more or less correct but the function just plain refused to cooperate.

I guess I was between builds or something because I got interested in the problem. While Jon took the more efficient path of carefully examining the parameters being passed and comparing their values to the documentation’s restrictions, I started traipsing through assembly in Xcode. You know, the fun stuff.

Of course, Jon found the answer first. It was a problem with the combination of colorspace and alpha parameters. The limitations are well-documented (if a bit overwhelming) in Apple’s Technical Q&A. In this case, Jon was fetching the values directly from a CGImage that had been loaded from disk. Can’t blame a guy for thinking that maybe a JPG image’s attributes might be suitable for creating a bitmap context!

Even after the bug was resolved, I continued digging into the framework via the debugger. I’m due for a complete retraining on Intel, but as long as I have my PowerPC machine around, I’m fairly comfortable zipping through the various API to see what really happens when an error occurs.

Sure enough, a few levels into the API, I spot an examination of the input colorspace, and an objection to the fact that it was only 24-bits per pixel. Great, I thought. If the API knows exactly what’s wrong, why doesn’t it let us know somehow, at least through a logging message or something. Then I spotted a call to “CGPostError.” Well, that’s interesting. A well-defined error reporting mechanism? The results of which the developer never sees? I traced along a while until discovered myself in a logging function, the parameter to which was this choice bit of text:

CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component;
	24 bits/pixel; 3-component colorspace; kCGImageAlphaNone.

Well! It doesn’t exactly point to the right solution, but it would have been nice to know! Thanks for not sharing, CoreGraphics. Why the heck does it go to all this work and not print out the result? I decided to dig deeper.

The framework has an internal function, “hasTerminal,” which seems to control whether logging to the console occurs or not. I guess the engineers on the CoreGraphics team are trying to be considerate and not spew logging messages all over your console log unless you’re actually, you know, debugging. Here’s the kicker – hasTerminal returns true if you are running from the terminal. All Jon had to do was test his app from the command-line and the exceedingly helpful logging message would have appeared.

But the “hasTerminal” function returns false when debugging from within Xcode. Bugger that debugger! How does hasTerminal decide whether to allow logging or not? It simply attempts to open “/dev/tty” with read/write access. If it is successful, the user must be running from a terminal? But somehow, when running from within Xcode, this test fails, and therefore logging is not done. I assume this has something to do with Xcode’s magic terminal-esque window, but the discovery raises two questions:

1. Should CoreGraphics limit its logging functionality based on assumptions about “/dev/tty”?
2. Should debugging in Xcode impact a target application’s ability to open “/dev/tty”?

These questions are posed in Radar #4538344- “CoreGraphics logging doesn’t appear withing Xcode”.

I ran into a search problem recently in one of my Xcode projects. Every time I conducted a particular search (in this case, the search term was “CFString”), my screen was littered with a series of cascading Xcode exception dialogs that look like this:

On the one hand, it’s great that Xcode goes out of its way to convey internal exceptions to the user. It means that they are less likely to just “let slide” exceptional conditions that would otherwise show up only in an archaeological dig through the system’s console log. On the other hand, when they spray dozens of them out at me while I’m just trying to search my project, it gets to be a real hassle to close them all after every search.

When I run into these kinds of errors from Xcode, I immediately start thinking of where my latest project backup is. It’s probably some kind of internal project format corruption. The last thing any of us wants to do is trash a project file and start from scratch, so it’s a good idea to keep backups of the project files (probably along with all your other sources, in the Subversion repository).

In this case I thought I’d be curious and try to get to the bottom of the problem. Since each of these dialogs corresponds to a raised NSException inside Xcode, I thought I’d attach with gdb and see what’s going on at the point of exception. This is what the top of the stack looks like while one of the annoying dialogs is being generated:

#0  0x928f9508 in -[NSException raise] ()
#1  0x95464098 in -[TSException raise] ()
#2  0x928f935c in +[NSException raise:format:] ()
#3  0x929c1794 in mutateError ()
#4  0x928e7a00 in -[NSCFString replaceCharactersInRange:withString:] ()
#5  0x928e7968 in -[NSConcreteMutableAttributedString replaceCharactersInRange:withString:] ()
#6  0x928f2a60 in -[NSConcreteMutableAttributedString initWithString:attributes:] ()
#7  0x98fc1004 in -[PBXFindResult initWithBookmark:textBookmarkResolvable:] ()
#8  0x98fc0e58 in -[PBXReferenceBasedBatchFinder reportBookmarks:findable:] ()
#9  0x98fbff3c in -[PBXTextBatchFinder doSomeFinding] ()
#10 0x98fbfd08 in +[PBXBatchFinder _backgroundBatchFinderNotification:] ()

Something to do with bookmarks! Well, I don’t even have any bookmarks in my project. Did I screw something one of those times I hit Cmd-D instead of Cmd-Shift-D to “Open Quickly?” I decide to set a breakpoint on the call to initWithBookmark:textBookmarkResolvable:, along with some exploratory breakpoint commands. I asked gdb to report to me what the bookmark argument looks like (“po” is short for “print-object”, useful for displaying Cocoa objects). I left my “raise” breakpoint, set to automatically continue, so I can tell what kind of circumstances immediately precede it. This is a “trap the thief” technique for pinpointing the misbehaving code. I let Xcode run wild and then look at the logged breakpoint information for clues as to what led to the assertion.

(gdb) b initWithBookmark:textBookmarkResolvable:
Breakpoint 15 at 0x98fc0ed8
(gdb) command 15
Type commands for when breakpoint 15 is hit, one per line.
End with a line saying just "end".
>po $r5
>c
>end

With the breakpoints in place, I return to Xcode and invoke my troublesome search. Looking back at the logged output in gdb, I see the following snippet (newlines added for readability):

Breakpoint 15, 0x98fc0ed8 in -[PBXFindResult initWithBookmark:textBookmarkResolvable:] ()
<PBXTextBookmark:0x08133700:rtn=2:fileRef=
<PBXFileReference:0x05e08d80:rtn=61:65562A49085CB7C5007AD50E:name='HackCFSocketStream.h'>
:timestamp=0:char-range={5485,8}:line-range={5485,8}:<range-type-0>={5485,8}>

Breakpoint 14, 0x928f9508 in -[NSException raise] ()

So, Xcode doesn’t like “HackCFSocketStream.h”? Aside from its obviously questionable name, what has it done so wrong? I take a look at my search results and sure enough, no HackCFSocketStream.h. Not only are the dialogs I’m getting annoying, they represent missing search results in Xcode!

I decide to try to narrow the problem down by doing a limited search on only the “bad boy.” I select the HackCFSocketStream.h file in Xcode’s files and groups tree, and do another search, this time selecting the “In Selected Project Items” scope-limiting option.

Son of a gun! No error dialog. It must be particular to doing a global search. I switch back to “In Project” and search again. No more bug. Gah! I seem to have “fixed” the bug by asking Xcode to limit its search scope to only the problematic file. I tried a few more problematic files, repeating the same identification method with gdb. Same results! Explicitly searching a selected file fixes the bug, apparently forever.

I tried to mix up the procedure a little bit. Instead of selecting the problematic file itself, I select the group that contains it. The bug still exists at this scope, but again, as soon as I select only the problematic file and search, the situation is resolved.

What I’m left with is a situation where I have a painstaking, yet effective method of ridding the project of this bug. Unfortunately, I have to wait until I encounter a search term that finds a problematic file. Then I have to identify the file and go in and do the magic cleansing search.

I suppose I might try to write a script or something that goes through and explicitly searches each file in the project. Will that clean things up? I should probably just revert to a backup project and hope for the best.

Update – More data points:

• It appears that it’s not searching the “problem file” but actually just viewing it in the Xcode editor that causes it to be “fixed.” I guess Xcode is probably reindexing or something when this happens. Rebuilding the index for the entire project does not fix the problem. So I guess I could work around this by writing a script to go through and open an editor window for every file in my project. We’ll see.
• A “problem file” is only problematic for a particular search term (or set of search terms, perhaps). For instance, a search of “text” in my source base causes a failure on a given file, but searching for another term present in that file brings it up just fine.

Update 2: The “fix” achieved by selecting an item is not permanent. It turns out that the error occurs only if the “bad file” is not currently open in Xcode. By selecting the file, it becomes open and stays open until explicitly closed. By explicitly closing the file (Cmd-Shift-W), I am able to reproduce the error again.

Update 3: Case Closed!

My curiosity wouldn’t let me leave this alone, and I finally tracked down the root cause of the problem. I have produced a very simple test project that exhibits the problem. If you’re curious, you can download the project here. Look at the single source file “TestSource.cp” for instructions on how to reproduce. I know enough about this problem now to summarize it in fairly brief form:

I tried to get it shorter than that, but I can’t! So what’s the bottom line? If your source file contains a multi-byte UTF8 character, Xcode mistakenly tallies the bytes instead of the characters when computing the offset into that line. In most cases, this just means that the contextual highlighting of the search result is slightly off, but if the “overshoot” caused by these multi-byte characters causes a search result range to exceed the end of the line, then it causes the very unsavory runtime exception I’ve described in this article.

This is better demonstrated by example. For instance, in the test project I’ve linked to, the UTF8 encoded source file contains a line like this:

Each of those bullets surrounding my initials is encoded in the file by the UTF8 bytes “e2 80 a2″. So what happens if I do a search for “Bullets” in this project? If the file is open, I get the expected result:

But if the file is closed, Xcode is not so savvy and interprets the file apparently on a “byte == character” basis:

See how the emboldened portion of the result is exactly 4 characters “too far?” That’s because the two bullets take 6 bytes, and Xcode assumes that two bullets should take only 2 bytes. The difference is the “slop” that gets inappropriately added into the range.

When the slop in the range takes you beyond the scope of the line, you get an exception. If I search the project for “danger”, I observe the edge case, beyond which no further range can be safely returned for the given line:

Searching for “dangerous” is just that. You’ll end up witnessing one of Xcode’s friendly error dialogs.

In summary: any UTF multi-byte character in your source file steals “safely searchable” characters from the end of the line. If any search in your project yields results that are at the ends of lines with multibyte characters, you will likely witness an exception and fail to see your search in the resulting pane.

Radar 4377633.

Workaround: Save your source files as some other encoding than UTF8. I don’t really know which encoding is best. I guess I need to figure this out. For this particular project, which had become a mish-mash of UTF8 and MacRoman encoded files, I decided to switch all the UTF8 files back to MacRoman. I won’t be able to initialize UTF8 strings with non-MacRoman typed constant values, but at least I’ll be able to search my project in peace!

People were discovering a cheezy implementation detail that required the user to completely remove their finger from the left side of the mouse before attempting to click the right side. It was hard to gauge how problematic this issue actually was. The reviewers were either completely appalled by the problem or absurdly nonplussed: “It’s no big deal, you just lift your left finger every time you click.” No big deal!?

Earlier this month I was working in New York for a week on-site with a client. They had bought an awesome new PowerMac G5 for this work, and I was delighted (but a little scared) to see that it came with a Mighty Mouse. To Apple’s credit, the computer ships with the mouse in “one button” mode. This is how they should continue shipping computers. In fact, they should remove the software that allows two-button mode to be enabled. This “feature” of the mouse is a total piece of poop. With the Mighty Mouse, essentially every click becomes a Russian roulette gamble. Did I click on the right side or the left side? Well, I know what side I clicked, but what side has the mouse decided I clicked?

I battled with the mouse for a few hours, trying to master the art of right clicking. Not only did the mouse fail to register my right clicks half of the time, the monstrosity managed to on occasion turn my left clicks into right clicks! I could swear it even swallowed clicks sometimes!

Just how bad is the Mighty Mouse? I have been using a two-button mouse on the Mac for about 5 years. I am completely accustomed to right-clicking everything in sight. I depend on the right mouse button, and I disabled it for my week with the Mighty Mouse. I became a control-clicker for the week!

It depresses me that this is the new “Standard Mouse” for Macs. It could have been so good. In my opinion it would be false advertising to call this a two-button mouse. I guess that’s why they just say it has “multibutton charm.”

For those of you who are concerned that the right clicking with the Mighty Mouse might be a problem, but are considering a purchase anyway: save yourself! I’m back at home with my utterly unstylish Wacom mouse, and loving every damned predictable right click I make.

Preparing to Hack

As with all modifications of Apple-provided applications, it’s a good idea to start by making a backup for safety’s sake. In the case of Keychain Access, you’ll discovery quickly that it’s not as simple as making a copy of the application in the Finder. It will warn you that “special permissions” prevent everything from being copied. There are two things at work here. First, the Keychain Access application and everything inside it is owned by root. Second, there are files inside the package with a “setuid” bit set, meaning that when they run, they get to inherit the privileges of root. To make this easy, I suggest in this case only backing up the “Resources” portion of the bundle, because that’s all I’m going to be modifying. You might get some complaints from Interface Builder that the nibs are “read only.” I just saved a copy and then copied the new nib into the English.lproj directory of Keychain Access.

Applying the Changes

Alleviating the broken “next responder” loop in the main Keychain window was as simple as defining an “initial first responder” for the window, and setting up an appropriate chain of “nextKeyView” connections. It seems that the responder chain as it ships from Apple is simply the default “emergency chain” fabricated by Cocoa when a developer doesn’t specify a particular chain. I decided to make mine start with the search field, and advance clockwise through the main table, “Category table” and “Keychain” table. The MasterView nib file contains the window whose contents can be fixed in this way.

While poking around in the MasterView nib, I also decided to change the keyboard shortcut for the “Info” button from Cmd-I to simply return. This has the effect of making the return key always open the item selected in the main table, which is fine because the return key doesn’t do anything special in the other tables in the window that can receive focus.

To give a keyboard shortcut to the “Show Secure Note” and “Show Password” items, I located the corresponding UI elements in the NoteEditor and PasswordEditor nibs. I gave them each the shortcut “Cmd-T” (for “Show Text”).

To alleviate the headaches of the “Save Changes” dialog’s missing keyboard shortcut for “No,” I only had to change the Localizable.strings value for that key from “No” to “Don’t Save,” which is probably what it should have been in the first place! Keychain Access uses NSBeginCriticalAlertSheet to display the Save Changes dialog, and as advertised, it will automatically accept Cmd-D as a synonym for clicking on the Don’t Save button. Sometimes “doing the standard thing” also means “doing the right thing,” and adds up to less work for a better product.

Now for the The Big Kahuna. The all-powerful “Allow Acccess” keychain authorization dialog. This bad boy’s unresponsiveness to keystrokes makes it the weak link in not only Keychain Access, but every other application that asks the user to approve a keychain fetch. Where does the Big Kahuna live? By running the command-line tool “fs_usage” while invoking the dialog, it’s easy to locate the nib in question. It looks like /System/Library/CoreServices/SecurityAgent.app/Contents/Resources/English.lproj/ConfirmAccess.nib is what we’re interested in. Again, the sensitive nature of this application means that I have to be careful to leave most of the existing app in place, while only backing up and modifying the resources.

Since I’m usually more interested in giving applications access “forever,” I not only added keyboard shortcuts, but moved things around a bit. I renamed the “Always Allow” item to “Allow Forever,” made it the default button, and moved it to the far-right. I gave the “Allow Once” button the simple shortcut of the “O” key. For some reason I was unable to give it a shortcut that requires the Cmd key to be held down. I’ll take what I can get! The resulting dialog looks like this:

And hallelujah! I can just “hit return” when it pops up.

The only item in my list of gripes which I haven’t been able to address in one way or another is the “Close All Windows” function. If Keychain Access were scriptable, it would be easy to write a script to workaround the problem, similarly to how I solved the problem in Terminal. As it is, I don’t expect to open up 500+ info winodws in Keychain Access in the near future, so I think I can live with that shortcoming.

Though vastly improved, by no means is the Keychain Access application perfect. In fact, this application and associated technologies are one of those “treasure troves” of undesirable behaviour. Often while looking more carefully at an unfortunate behavior, with the intention of reporting a bug, my attention ends up snowballing into a series of observations of how an application could be better designed.

With Keychain Access, a major area it is still lags in is the keyboard navigation department. Now that I can easily search my keychain items, it would be nice to be able to do so without ever reaching for the mouse. At this point I have a keyboard shortcut set up to open Keychain Access, and from within the application I can press Cmd-F to start a new search. But when I see the beautiful shining result in the filtered list, there’s no way to navigate back to it! Pressing Tab from the search field does exit the search field, but it switches focus to the “Keychains” sidebar table. Who wants to navigate to that? Pressing Tab again switches focus to the “Category” table. Arrow-keying through the various items in this table causes a live update of the main table, but no amount of tabbing will get you there. It’s a “next responder dead end!” (Radar 4327828).

Once I’m focused on the main table, there are other hiccups. It took me a while to figure out that I can in fact bring up the secure item’s “info dialog” by pressing Cmd-I. This shortcut is attached to little “i” button at the bottom of the screen, and unfortunately is not available from any menu item. The friendliest way to handle this would be to have the tableview interpret “return key” as a signal to “open the selection.” The return key is often interpreted as a request to either open or edit a selected item. In this case, by opening the Info dialog, it would do both. (Radar 4327871).

But anyway, at least I can get info! The fun stops there, however. I am looking at the info window, but the thing I want to see: the secure note, web password, whatever, is hidden from me. I can see the checkbox that needs to be clicked to reveal the secrets, but I soooo don’t want to reach for the mouse. There should be a “Show Secrets” keyboard shortcut for any secure item that has such a checkbox. (Radar 4327842).

In the process of trying to figure out whether there was a convenient shortcut for “show secrets” in the info dialog, I managed to stumble into accidentally editing the item. When I closed the item, a dialog came up asking me if I’d like to save the changes. I tried the typical “Don’t Save” shortcut: cmd-D. No such luck. The “Save” button is throbbing blue so its keyboard shortcut is taken care of, but the “No” button seems to require a manual mouse click. As a long-shot try, I press “Cmd-N” to match the “No” of the button’s text. At first this seems to work, but instead something very fishy happens. Pressing Cmd-N, even while being faced with a modal sheet in the Info dialog, invokes the application’s higher-level “New Keychain Item” functionality. The Info window and its pending sheet disappear and a sheet appears on the main window asking for details about my new item. I thought the window had been dismissed, but later I found it hiding behind the main keychain window. It had simply been ordered backward. The “Save Changes” dialog should support a keyboard shortcut for “Don’t Save.” (Radar 4327889).

Let’s assume all the above bugs get fixed, and I’m sitting pretty in Keychain Access land. I hit my Keychain Access keyboard shortcut, press cmd-F, search for “etrade,” navigate to the main table, press return to open the item, press a keyboard shortcut to reveal the secret password, and am faced with the “Keychain Access wants permission” dialog. First of all, isn’t this the Keychain Access application? I’ve just unlocked my whole keychain. We’re staring at my repository of goodies. Can’t you work out a deal or something? You seem to be “in good” with the Keychain. Once you show the secure text for an item, you can choose to “Always Allow,” but that only gives permission for that specific item! So you’ve got to enter the password and click “Always Allow” at least once for every freaking item in your keychain. There should at least be a preference for easily saying “Always give Keychain Access access to secure items.” (Radar 4327935).

I thought maybe I could do something spiffy like go in and manually set all of the items to allow Keychain Access to access them. Since you can “preload” this setting in the “Access Control” pane of an item’s info window, I thought maybe I could select all of my items and add the same access privilege for Keychain Access to them. Oops! I selected all 500+ items and hit Cmd-I. Now I’ve got 500+ Info windows cascading across my screen. To add insult to injury, Keychain Access doesn’t support a “Close All Windows” option, though quitting and relaunching did the trick. (Radar 4327956).

Having to give individual authorization to each and every item wouldn’t be so bad if the authorization dialog itself wasn’t so poorly keyboard-navigable. The dialog pops up, asks you to give authorization (by typing of course… at the keyboard!) and then you have to go over to the mouse to click either the “Deny,”"Allow Once,” or “Allow Always” items. Gah! Presumably this is done to prevent somebody accidentally giving permission to a malicious application, but you’ve got to enter the password before doing so! That gives me plenty of opportunity to think twice before allowing or denying the action. At least the “Allow Once” button should be default and automatically clicked upon hitting return from the password dialog. The “Always Allow” button should ideally also have some keyboard shortcut. (Radar 4327981).

I finally traced it down to an insidious, parasitic relationship between the standard font panel and Interface Builder.

It seems that when the Font Panel is enabled, Interface Builder is liable to start choking on things like mouse clicks and drags. I have observed repeated delays of up to 2 or 3 seconds, just to click on a UI element in IB! And this is a on Dual 2.0Ghz G5! Pity the poor iMac user! When the Font panel goes away, responsiveness comes back 100%. If you’re just a little bit of a clutter-rat, as I am, then you’re liable to leave your Font Panel open as you forge ahead with your interface design. It never occurred to me that this might be robbing precious minutes from my work day!

This problem can be reproduced easily on Mac OS X 10.4.2 with Xcode 2.1 installed. Follow these steps to reproduce the problem yourself and gape in awe:

1. Launch Interface Builder, creating a new “Cocoa Application” document.
2. Observe the quickness with which you can click and change the selection between each of the 4 instance icons:

   

3. Press Cmd-T to bring up the Font panel.
4. Resize the Instances window such that the icons rearrange. For some reason this helps reveal the problem. I don’t know if this is a caching issue or what:

   

5. Now try clicking between the icons again. It may take a few rounds through, but you will soon start to observe hideous delays between mouse click and selection change.
6. Once you’ve observed the slowdown, close the Font panel by again pressing Cmd-T. This should return responsiveness to normal levels

This is a small demonstration of what it’s like to have this kind of delay plague your entire design session. The delay applies to anything clickable, selectable, draggable, etc., in IB. This includes all UI elements in your windows, views, etc.

So if you’ve been plagued by mysterious, dramatic reductions in IB responsiveness. Make sure your Font panel is closed. It may be sucking the life out of IB!

I’d be interested to hear if any readers can or cannot reproduce this on their own machines. For now I’m assuming it’s widespread, and I’ve reported it as Radar 4293149.

This cool effect depends on a chain of willingness by NSView to “pass along resize fever.” When a view gets resized, it optionally asks all of its children to resize, and they ask their children to do the same. If a “lazy” parent chooses not to pass the message along to its children, resizing below that node doesn’t take place. Fortunately, NSViews are by default documented to be “ambitious” in this regard.

I was recently confused and perplexed by a failure of my custom views to react to the containing window’s resizing. These views are dynamically added to an empty window just after it has been loaded from a Nib, after which time I expect them to behave according to their preset resizing flags. The empty window has a very simple view hierarchy: just a plain-jane NSView designated to hold the contents of the window (which also has as a superview the window’s frame). Every time I’ve ever created a window in Interface Builder, the resizing has worked as expected. This time it doesn’t.

I double check the resizing flags on my subviews – everything is order. But they don’t respond to resizing the window! When the window resizes, the contentView of the window should resize, and my custom subviews should resize/reposition. That’s how things work! To see whether it’s something funky about my custom view, I decide to test a basic resizing scenario by adding an arbitrary subview to my empty window. I choose an NSButton and place it in the upper-right corner of my window, with its autosizing mask set so that it stays there. I run my program, and lo and behold, now *everything* works, including my custom subviews! The mere presence of the button has cured my woes. But I don’t want to leave a bogus button (or other view) in my window just to work around this problem.

I finally get the bright idea of checking the “autoresizesSubviews” flag of the window’s contentView. If somebody is responsible for setting this flag to YES, I’d like to know who it is, so I can convince them to do it for me! I add a breakpoint on NSView’s setAutoresizeSubviews: method, and relaunch my application (with the test button still in place). I land in AppKit’s nib loading code, where I confirm that parameter is YES:

#0  0x9364be24 in -[NSView setAutoresizesSubviews:] ()
#1  0x9364baf0 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] ()
#2  0x93637fc4 in loadNib ()

I take out the test button to compare notes against my “broken” case. Sure enough, without my bogus button, the call to setAutoresizesSubviews never gets called! Could it be that NSView is documented as automatically resizing subviews by default, but in fact depends on being set that way by the Nib loader? Since 99% of the views that people care about resizing probably start their lives in Interface Builder with subviews from the get-go, I suppose it’s possible. But the documentation says otherwise! Perhaps the documentation writer made an assumption? This is easy to test, especially since I’m already in gdb. I just create a throwaway NSView object and test the property:

(gdb) p (BOOL)[[[NSView alloc] init] autoresizesSubviews]
$11 = 1 '\001'
(gdb)

Phew! I breathe a sigh of relief to learn that yes, NSView does conform to its documentation. The setting by the Nib loader is just a paranoid double-check, I guess. So who’s doing me wrong? If a plain-jane NSView comes with autoresizing for free, and my window’s content view is a plain-jane NSView, then somebody must be setting the flag to NO on my behalf. Damn them! But we just observed that the breakpoint on setAutoresizesSubviews: never gets hit for my window’s content view. What’s going on?

It becomes clear to me that my window’s contentView was “just born wrong.” In Cocoa, an object that starts out on the wrong foot was probably archived that way. I become very suspicious of Interface Builder, who was responsible for packing up my NSView but apparently included a nasty surprise in the process of doing so. To confirm my suspicions, I attach with gdb to Interface Builder, set a breakpoint on setAutoresizesSubviews, and resave my Nib. Surely this will reveal the wrong-doing. Bzzt! I have tried and tried but witness no call by IB to setAutoresizesSubviews with a “NO” parameter.

So let’s review the facts. We’ve got a situation where an NSView’s autoresizesSubviews flag turns to NO, but no code on this known planet is culpable (at least through the exposed accessor). If the flag is turning to NO and nobody is calling the accessor, then the odds are that this is an inside job. Why would an NSView turn against itself like that?

I try to get NSWindow out of the picture. There are too many potential bullies on this playground. If the problem is that NSView objects without children get freeze-dried in IB and end up without the autoresizing flag set, then I need to simplify the test case. I create an empty NSView in IB by dragging an NSView to my document window. I don’t do anything to it. Just add an outlet instance var to my window controller, named oBadView. I break on awakeFromNib and examine the simple view from the debugging console:

(gdb) p (BOOL)[oBadView autoresizesSubviews]
$1 = 1 '\001'
Current language:  auto; currently objective-c
(gdb)

So It’s not a simple NSView issue. I further refine the test (and assure myself of sanity) by dropping a fresh NSWindow instance into my nib, and checking its contentView’s resizesSubviews flag at launch time. It suffers! Well, at least I have a simple way to explain it in the bug report.

I don’t really know where Interface Builder’s windows come from. I know that if they are instantiated in my nib, there is some voodoo freeze-drying that goes on, somewhat analogous to archiving and unarchiving objects with the NSCoder protocol. But adding a new window to my nib causes no break in NSWindow’s init methods. I figure there must be some sort of prototype freeze-dried window that gets instantiated and copied as needed to spawn new windows. But this problem is more insidious than that: if I create a window, and add items to the contentView of that window, I end up with the autoresizes flag set to YES. Now if I remove those items, the autoresizes flag is back to NO, even though I never saw a setAutoresizesSubviews call! I think there must be some kind of private IB “window object” that gets passed around and mucked with. Perhaps this object is what gets freeze-dried and turned magically into a true NSWindow only after my app launches.

I’m not one to give up easily, but in this case, I admit it: this bug has bested me. Considering the workaround is as easy as sending a “setAutoresizesSubviews:YES” message to my window’s content view at nib awakening, I’m happy to let the Interface Builder team at Apple figure out the finer details. (Radar 4290256).

1. Locate the attachable files in the Finder.
2. Select them and start a drag.
3. Cmd-Tab to activate Mail.
4. Cmd-N to create a new mail message.
5. Drop the drag into the content of the new message!

It’s just … downright amazing that you can do this! So where are the bugs? There are two major shortcomings I’ve observed in Apple’s overall fantastic implementation:

Radar 4270813 – Can’t cancel drag outside of initiating application

Normally when you start a drag and end up with second thoughts, you can rely on the effectiveness of the escape key to reject the drag without any worries that you might be accidentally moving a file or object to some new, unfathomable location. For some reason this mechanism simply stops working once you’ve switched to an application other than the app that originated the drag. So, assuming I want to safely cancel a drag that I’ve started and then switched applications for, I have to now navigate back to the original application just to hit the escape key and cancel the drag!

For instance:

1. Navigate to the Finder and begin dragging a file.
2. Cmd-Tab to another app, say, Mail.
3. Hit the escape key. No effect.
4. Cmd-Tab back to Finder.
5. Hit the escape key. Drag cancelled!

What a drag! The cancel key should kill the drag safely regardless of where the user has wandered. This is especially problematic if, for some reason, your short-term memory fails you and you can’t remember which application originated the drag.

Radar 4270824 – Can’t completely switch back to drag-originating app

So, once you switch back to the originating app you can hit cancel and breathe a sigh of relief. The problem is, switching back to the originating app while the drag is still in place produces another bug, which is that although the originating app is now “front-most”, none of its IU (not even its menu bar) has yet been brought to the front. So it’s not only confusing, but if you decided you wanted to drag to the originating app after all, you’re out of luck. You’ll have to cancel the drag and start over.

Illustration:

1. Initiate a drag in the Finder by selecting and dragging a file from a folder list.
2. While keeping the drag alive with the mouse, Cmd-Tab to another application, say Safari.
3. Decide you don’t want to drag to Safari after all, and Cmd-Tab back to the Finder.

Result: Although the Finder is somewhat active, none of its windows have come forward, and the menu bar still says “Safari.”

Workaround: If you can glimpse any part of a Finder window’s content, then dragging the item to this content and “moving it around” seems to trigger full activation of the Finder. I imagine it’s similar for other applications.

What a drag! Cmd-Tabbing to an application should always bring it forward.