In an unusual move, Steve Jobs has taken the text podium on the Apple web site, writing about his Thoughts On Music, though it might be more aptly titled “Thoughts on DRM” (Digital Rights Management).

“Imagine a world where every online store sells DRM-free music encoded in open licensable formats. In such a world, any player can play music purchased from any store, and any store can sell music which is playable on all players. This is clearly the best alternative for consumers, and Apple would embrace it in a heartbeat.” — Steve Jobs

There’s been a lot of speculation over the years that Apple either would or wouldn’t support DRM if the music industry didn’t force them to. I find it interesting to at least hear lip service from Jobs to the idea that DRM is bad for consumers.

But this kind of public “for the record” stance seems highly unusual. In the wake of the Apple vs. Beatles settlement, I can’t help but wonder if Apple is setting the stage for some kind of DRM-defying move. If they could sell the Beatles exclusively and DRM-free, what kind of precedent would that set for the rest of the industry?

As the article wraps up, it becomes clear that the probable purpose of the highly visible stance is to defend Apple against claims by some European countries that iTunes is against their consumer protection laws. I think Jobs (or his researchers) makes an excellent point in drawing attention to the significant European ownership of the media companies who are apparently responsible for demanding DRM protection. It will be interesting to see if this sparks a public debate between Apple and the music companies.

Way back in the MPW days, I used to rely heavily on an extension for the IDE that put powerful pasteboard manipulation tools in the window header. Essentially these tools let you treat your pasteboard like a stack, so you could easily accumulate multiple copies and then paste them all out at once.

For some dumb reason, I’ve been living without such conveniences for several years now. I know there are many 3rd party products that add an epic amount of functionality to the standard copy and paste of the system, but I’m not really interested in running a separate application for this purpose.

It occurred to me that this would be a perfect use of Xcode’s Menu Scripts. Xcode not only supports the addition of custom scripts to the menu bar, but supports a unique format by which the scripts can advertise keyboard shortcuts, and integrate seamlessly with Xcode’s text editor. For instance, you can use a script to process the selected text in Xcode and spit back out something else in its place.

Append To Pasteboard is a simple python script that takes advantage of the “pbcopy” and “pbpaste” commands to tack whatever you’ve selected in Xcode on to the end of the existing pasteboard. You stick this within your (horribly located) user scripts folder, where you must name the folders and files with numeric prefixes to inform Xcode where they belong. For example, the script lives in my home directory:

/Users/daniel/Library/Application Support/
	Apple/Developer Tools/Scripts/
	10-User Scripts/1-DCJ/

Unfortunately Xcode doesn’t handle the situation where some scripts come from your home directory, and some come from the /Library installation directory. So I put everything in my home directory. The “10-User Scripts” is how I tell it to name the menu bar item “User Scripts.” The “1-DCJ” folder is the folder with all my custom scripts in it, and since it is “1,” it comes before all of Apple’s standard scripts that I copied in (10-Open, 20-Search, etc). The process of providing scripts to Xcode is ugly but when you finally get it all put together, this is what you end up with:

Now it’s a snap to cruise through a .m and accumulate method declarations, for pasting into a corresponding .h. Note that the script always appends a newline to the existing pasteboard, which could be annoying depending on what you want to use it for. Since I envision myself almost always double-clicking a function or method declaration and appending it to a list, I find this behavior to be most convenient.

Thanks to Jon Wight for helping with Python.

Update: Any productivity gained by using this macro was certainly lost as I tried desperately to debug Xcode’s latest propensity to “beachball” on launch. Finally, I attached with gdb and found a telling backtrace. Hmm? Yep, when I “zipped” the script for upload to the blog, I left a zipped copy in the scripts folder. Next time I launched Xcode, it choked big time on trying to treat that zip file as a script.

There has been some speculation among my programmer buddies that Omni has lost a developer. Given the recent job listing for a Senior Cocoa Coder, many figured they must be restocking the talent. I figured they were just growing (and they may well be), but it turns out they did lose a developer, and quite a veteran at that.

Len Case is Omni CEO Ken Case’s brother, and apparently left the company in November, after 13 years of service, to become the lead developer at STX. He tells an interesting personal story about the decision, explaining that he thought about leaving in past years, but hesitated because of how his brother might take the news. The entry also includes some great context surrounding Omni’s formation way back when.

The Omni bio page still lists Len as a developer for the company, but perhaps this is a sort of “emeritus” honor (or they’re just slow in updating). What did Len do at Omni? The bio is purposely vague, but it looks like OmniDiskSweeper may suffer for his departure. By peering into the past, I gathered clues that indicate maybe his contributions were mostly in the consulting services that Omni provides to other companies. By the way, peering into the past is fun. And embarrassing. Don’t look me up. Please.

These details were all discovered after following Rentzsch’s incredibly vague del.icio.us entry pointing to Len’s blog.

TUAW points us to a a choice Newton video, from 1993. In spite of some dated production qualities, this video could serve as a template for marketing the greatest features of the iPhone. Syncing, address books, To Dos, “instant messages.” Lots of features ripe for comparison with the iPhone and other modern devices. It even “squirts” (beams) like a Zune!.

The best part of the video? In the midst of all this enlightened modern living, the video shows a man scribbling away on his Newton while talking on the phone. A pay phone! If only they could somehow combine those two devices! I also like the knowing look and raised eyebrows one worker gives to another just before she “beams” him a message. A subtle suggestion that Newton might actually get you laid.

I never used a Newton much, although I occasionally had my hands on one at work for some debugging purpose. Some of the design considerations really pop out, like the fact that the Newton was almost entirely “soft button” based, much like its nascent offspring. The soft QWERTY keyboard is even reminiscent of the iPhone’s, except that with the Newton it was only intended to be used when the handwriting recognition made a mistake.

Which it did. A lot. Many people consider the failure of adequate recognition on the Newton, and the basically functional compromise of Palm’s “Grafitti” to have been the death blow for the gadget. Amid all the happy music and smiling people, you can tell the issue was weighing heavy on Apple’s mind, too. Halfway through the video the topic changes to “handwriting tips” and more or less stays on the subject for the rest of the promo.

If Apple presents iPhone along with a promotional video that is half devoted to teaching users how to workaround the device’s bugs, then we’ll know it’s doomed.