With sincerest apologies to the developer, I feel compelled to mention that when I see the name "ShiftIt" my brain switches the "f" and the "t".
I even started to type it that way just now. I must have some combination of dyslexia and Tourette's.
I finally cleaned up and posted the notes and code from my presentation at the last CocoaHeads. See here.
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.
[Presented at the joint meeting of CocoaHeads-NYC and the New York FileMaker Developers Group, July 8, 2010. I've heavily edited this since giving the presentation. The original text was much more sparse.]
Therefore:
App is called "Hotness".
Cocoa patterns and techniques:
App is called "WhatKeys".
Cocoa patterns and techniques are same as in Hotness, plus:
Here are links for the source:
[UPDATE 2011-01-12: I've put the code in GitHub and changed the above links accordingly.]
To compile the example code you'll need Apple's Developer Tools, which you can get for free here (requires registration). After installing the Dev Tools, double-click an xcodeproj file to open the project in Xcode.
[UPDATE 2001-02-09: This post used to be a WordPress "page", but I decided it should really be a regular blog post, so here it is.]
TUAW reports on a study by a firm called MyType, with a sample size of 20,000. The upshot? iPad owners are "rich and smart, but also spoiled and cruel."
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.)
Here's another usability glitch when double-tapping to select a word on the iPhone.
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.