On a related note, the developer of the ShiftIt app I mentioned has a blog called "Cocoa Tips and Tricks." One of his posts is about implementing hotkeys, and one of the comments to that post mentions that Snow Leopard has an NSEvent method that makes it real easy. I see from the doc that:

Key-related events may only be monitored if accessibility is enabled or if your application is trusted for accessibility access (see AXIsProcessTrusted).

and:

Note that your handler will not be called for events that are sent to your own application.

I'll have to check whether the DDHotKey library I used has these limitations. Regardless, this is nice to know.

I even started to type it that way just now. I must have some combination of dyslexia and Tourette's.

Hotkeys for running AppleScript was a requested topic. Since I didn't know anything about global hotkeys, the existence of DDHotKey and ShortcutRecorder was convenient to say the least.

Since some of the target audience was new to Cocoa programming, I sprinkled helpful comments and links throughout the code, but not nearly as many as I could have — it would have been like trying to write a whole book in comments.

I was surprised how many conceptual topics even a simple Cocoa app can get into that I take for granted. It just goes to show, even the best example code is not enough to get a new Cocoa programmer started, not in a serious way. You really have to commit a bunch of time and work through Apple's conceptual documentation or something like Hillegass's book. Or go to a good training camp like Hillegass's Big Nerd Ranch.

In other words, we are winners. I knew it!

As for the iPad haters:

"bashing the iPad is, in a way, an identity statement for independent geeks."

In other words, they are losers who do exactly what they claim Apple fans do: rabidly focus on a piece of technology because it makes them feel cool.

(In case it wasn't clear: my comments are purely tongue-in-cheek. Mostly.)

Suppose you're in a notes app and you're looking at a note with the keyboard deactivated. Double-tap a word near the bottom of the screen. The word is selected, as it should be. In some apps, the keyboard slides up to allow you to start editing.

The problem is that the second of your two taps lands on a point that lies within the keyboard area, so you unintentionally type whatever character corresponds to the key at that point.

This happens in Notespark and Simplenote, because they bring up the keyboard, but not in Apple's Notes app. In Notes, single-tapping brings up the keyboard but double-tapping does not, perhaps because of this very problem.

I'm not sure whether this should be considered an app problem or an OS problem. I lean toward OS, because from the user's perspective touch events should be captured by the view I actually touched. I suspect the issue is related to the way Core Animation works. The first tap immediately adds the keyboard into the view hierarchy, so technically the second tap really is in the keyboard, but you don't see the keyboard until it animates into place.

On the other hand, I would think the app should be able to deal with this fact, though I haven't thought the logic through. Maybe Apple's approach in their own app should be a hint that there's no good solution.

I wanted to include screen shots, but again, I don't have time.

Summary: Double-tap selects a word instantaneously if keyboard is off, but with a long delay if keyboard is on.

Steps to Reproduce: In the iOS Notes app, edit a long document (mine was 8K, about 600 short lines). Make sure the keyboard is active. Double-tap a word to select it. It takes a second or two to select the word. Since there is no visual feedback during that time it is not clear whether the double-tap was detected, and whether it was done in the intended spot. Now tap "Done" to deactivate the keyboard and double-tap a word. Now the word is selected immediately.

Expected Results: Immediate selection of the double-tapped word.

Actual Results: A delay of a second or so.

Regression:

Notes: I saw this on an iPhone 4.

I originally saw this when editing a todo list in the Notespark iPhone app. (I have a todo list that was intended to be a quick "do it now" list but grew to 8K and 600 lines, so you can see how good I am at getting things done.) At first I blamed Notespark, which hasn't been updated in a long time so I guessed maybe Apple had changed the text APIs and Notespark simply needed to modernize. But I saw the same problem in Simplenote and Apple's own Notes app. This is with iOS 4.01.

I see the problem does not happen on my iPad — double-tap always selects the word instantaneously. I don't know if this is because the iPad has faster hardware, or because it's only running iPhone OS 3.2.1.

Speaking of modernizing, I really, really want a version of Notespark for the iPad. I'd pay a couple of bucks for it. Notespark says they're looking into it, but I don't understand why there would be hesitance or delay. Maybe they don't see sales numbers justifying the development cost? Maybe I'm underestimating the effort to design a good UI around the larger screen space (I'm thinking of the conflict resolution UI)? All I know is, I would switch to a different notes app in a minute if there was one that supported three-way merge and had an iPad version. I haven't researched this lately, so maybe there's a competitor I don't know about.

That's something else I don't understand — why nobody else but Notespark seems to think merging is important. Maybe I use notes apps differently from most people.

Maybe I should finally get my iOS developer chops up to speed and offer to do the work for free.

I didn't get the bumper originally but did after a couple of weeks — not at all because of any antenna issues, but to keep the phone from sliding off my desk with the slightest accidental nudge.

Benefits of the bumper:

• The rubber edges provided a nice amount of grip so that the phone stayed in place.
• The phone was lifted slightly off the table, so if there was a bit of grit on the table the glass on the phone wouldn't get scratched.
• I could lay the phone down on its face without fear of scratching the front; this gave me slightly more privacy in the event that I got a sensitive text message.

Drawbacks:

• The bumper doesn't fit in the dock.
• The slot at the bottom is too small for the connector on my third-party docking cables.
• The rubber is a little too grippy; it snags against my pocket when I'm pulling the phone out.

I don't mind the first drawback, because I don't use a dock. I don't mind the second, because I have plenty of Apple cables. The pocket-snagging, though — that was a minor annoyance but one that was repeated many times a day.

My solution was to remove the bumper and instead apply four translucent rubber dots to the back of the phone. As you can see from the packaging, these flat dots are also called "bumpers." They are originally to keep lamps and vases from sliding and scratching furniture.

Benefits of the dots:

• I'm back to the original sleek feel of the phone, which I like.
• I get the gripping benefits I got with Apple's bumper.
• The pocket-snagging is no longer an issue.
• There is airflow under the phone, sort of like what Bluelounge's Cool Feet do for laptops (the effect is probably negligible, but the phone does get pretty warm sometimes).
• The dots cost practically nothing.

I could probably run a scam on eBay advertising brand-new iPhone "bumpers" for five dollars apiece.

Drawbacks:

• The back of the phone is now ugly — but when I'm using it I only look at the front anyway.
• I'm no longer comfortable laying the phone face-down — but that's a tradeoff I can live with.
• Pocket lint will gather around the edges of the dots — but I can live with that too.

I forget exactly when I did this, but after a few days the dots have stayed stuck on pretty well. No signs of peeling. I got mine from Bed Bath and Beyond, in a package that included more dots and more kinds of dots than I needed. They might also be available at hardware stores or office supply stores.

This has been news for at least a day or two:

For those who want to see how it worked "under the hood", we are pleased, with the permission of Apple Inc., to make available the original program source code of MacPaint and the underlying QuickDraw graphics library.

What's odd is how the web page at the Computer History Museum made Safari 5 freak out when I tried to post the link on Facebook. I tried pasting into the Link field, expecting Facebook to display a text excerpt and select a preview image like it always does. Instead I got an empty window with this in Safari's address field:

http://www.facebook.com/ajax/composer/attachment.php?
data[url]=http%3A%2F%2Fwww.computerhistory.org
%2Fhighlights%2Fmacpaint%2F
&app_id=2309869772&stream_id=724065703
&composer_id=c4c46efc1298210b2a81b4

I thought I could get around this by pasting the link into the "What's on your mind?" field. Now Facebook did display an excerpt and an image, but the "Share" button had no effect.

Ironically, Safari's "View Source" menu item is disabled when I go to the page in question.

What could be so freaky about a simple web page? From a quick glance at the page source (viewed in Chrome, which had none of the above problems), it seems to be basic HTML and JavaScript.

Seems like I should report a bug to either Apple or Facebook — probably both — but I'm kind of busy now.

UPDATE: As I learned from Marquis's comment, this happens in Safari with any link — even plain old http://www.google.com. So it has nothing to do with the Computer History Museum site. I tried the latest versions of other browsers:

• Opera 10.60: Behaves like Safari (blank window with AJAX URL).
• Firefox 3.6.7: I paste the link and hit "Attach", and nothing happens.
• Camino 2.03: No problem.
• Chrome 5.0.375.99: No problem, as I mentioned earlier.

Apple's attempt to draw RIM into Apple's self-made debacle is unacceptable. [...]

CrackBerry is hosting a poll which they say refutes Jobs's claims:

Update: Well, after a few thousand quick votes it seems some 86% of us BlackBerry Bold 9700 users think El Jobso's evidence is a big pile of BS. As for the 14% who think it may hold water, well, I'm sure some of those must be legit… but the numbers speak for themselves. Sorry Steve – it seems you became part of the media you like to beat up on with this one… making a story where one doesn't actually exist.

Let me see if I understand this paragraph correctly.

1. If a vast majority of users don't have a problem with your phone, there is no real problem and it's irresponsible to drag that phone into a media circus. More importantly, this logic doesn't apply to the iPhone, only to BlackBerry phones.

2. If a minority doesn't agree with your predicted poll result, they're probably lying, but the majority voters in your self-selected audience are, it goes without saying, beyond suspicion.

Got it.

(Via Gruber.)

On another note, I'll be uploading files from last night's CocoaHeads in the next day or two — I want to clean up some things.