Archive for November 2009
Now, you may be saying that we deserve it for using Apple’s trademark but no, in Australia it doesn’t work that way. Our Trademark Act of 1995 states that if “the person uses the trade mark in good faith to indicate the intended purpose of goods” then we are not causing an infringement. When we created the name back in 2003 it was quite simple: Apple was advertising “Rip, Mix and Burn” and my software ripped your iPod back to your computer. Hence, the logical conclusion was iPodRip.
They couldn’t rename it “PodRip,” either. John Gruber:
That’s crummy. “iPod” is Apple’s. “Pod” is just a word.
Update: Apple changed its mind.
Mike Ash has a great list of Cocoa APIs that are subtly dangerous. Note that since
NSBundle isn’t threadsafe, neither is
Drawing my cues from the original and best metro diagram, H.C. Beck’s wonderful London Underground diagram, I have rendered the Interstate system in a much simpler form. I have made the “major” highways (those divisible by 5) the framework of the map, with the “minor” highways reduced in importance and rendered as thinner grey lines. Even with these highways, a difference in the greys indicates whether they are even-numbered (west-east) or odd-numbered (north-south).
Now I feel like playing Ticket to Ride.
Jens Ayton proposes that adding generics to Objective-C would allow for better static analysis with no changes at runtime or to existing code. Jesper concurs. This seems like a reasonable idea, although I’m not sure it’s worth the hassle and visual clutter. I don’t think improper typing is a major source of bugs.
Marcel Weiher points out that blocks are noisy compared to HOM. Of course, HOM can be more concise because it’s so much more limited. Chiefly, it requires predefined methods. He argues that this is a feature, not a bug, that HOM encourages good code and blocks encourage bad code. That’s not wrong, but with power comes the ability to shoot yourself in the foot. Blocks make the language much more expressive and solve problems that HOM can’t. Used judiciously, they can make for clean code.
If you’re not a developer and are just looking for some excellent discounts on a huge variety of Mac applications, check out the One Finger Discount page and see what everybody has to offer.
I’m pleased to be participating as a developer and a customer.
BBEdit 9.3 has a bunch of neat additions:
- Live multi-file search results.
- Awesome new bbfind command-line tool.
- I can now open a the multi-file search for the current project or disk browser with a single keypress.
- Dropping a folder on BBEdit can now create a temporary project (like in TextMate).
- Quick Look in projects and disk browsers.
- Per-language tags files to store common completions.
- A language module for Makefiles (very rudimentary coloring, though).
ASObjfunction creates an
ASObjectproxy object for any NSObject that implements
invokeCommandtakes care of marshalling the parameters into an AppleEvent, sending it, and unmarshalling the return value into an NSObject. The name of the command is the name of the name used in AppleScript, not the Cocoa implementation.
Then his controllers use the proxy objects to talk to the model through AppleScript.
If you want to right-click, you’ll need to get used to lifting your left-most finger off of the mouse in order for it to register correctly. If you have an Apple Mouse, you’ll already be used to it—I do it without thinking, but that doesn’t change the fact that lifting your index finger into the air so your middle finger can click is a more stressful position for your hand.
I use a Mighty Mouse with the main surface set as the primary button and the scroll ball set as the secondary button. This frees me from worrying about which side of the mouse I’m clicking and which finger I’m using, as my hand will be in different positions depending on whether I was using the scroll ball to scroll.
How is the user supposed to “know” and remember intuitively that click-through now only works in icon view mode and not in list view mode and column view mode? And how is the user supposed to “know” and remember intuitively that, even though click-through no longer works, “double-click-through” (to coin a phrase) still does?
I believe click-through in Mac OS X is fundamentally broken. It should be turned off for all interface elements, except for a few standard elements which always receive click-through and have hover states to clearly indicate that they are clickable.
I believe click-through should be disabled entirely.
The November issue of ATPM is out:
- MacMuser: Chasing the Dragons
- MacMuser: iPhoniness
- How To: Making Your Own Speakable Items
- Desktop Pictures: Mt. Shasta
- Out at Five
- Accessory Reviews: AutoPower and ACpower
- Software Review: LogTen Pro 5.1.4 and LogTen Mobile 2.4.1
- Accessory Review: Loop Leather Sleeve
- Software Review: ShareTool 1.3.1
- Hardware Review: Voyager Q
- FAQ: Frequently Asked Questions