Sci-Fi Hi-Fi

Good news for anyone who has ever wished Cocoal.icio.us did X or had Y: now you have the power to make your dreams come true (well, your software-related ones anyway). You heard me right: I finally made good on my promise to clean up the Cocoal.icio.us project and open source the code. Cocoal.icio.us is now in CVS and has a project page at SourceForge. The code (complete with an Xcode project) can be checked out anonymously using the following CVS commands:

cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/cocoalicious login
cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/cocoalicious co cocoalicious

(Update: Thanks to Sean Santry for pointing out the errors in the previously posted commands. Have I ever mentioned how much I hate CVS?)

This doesn’t mean I’m abandoning Cocoal.icio.us development by any means, just that I recognize that it’s going to take a lot more than the precious few hours I can devote to side project development every week to acheive its full potential. I’ve already had my homeboy Andrew Wooster working on a particularly exciting new feature that we should be able to check in shortly (I’m going keep it a surprise for now), and just having one other developer on the project has made me very optimistic about Cocoal.icio.us’ future.

So, if you’re a Cocoa developer interested in working on a cutting-edge project that encompasses many of today’s hottest buzzwords (desktop search, folksonomies, faceted classification, web services, REST) and OS X technologies (Cocoa Bindings, SearchKit, NSXML, WebKit, Foundation URL APIs) you might want to have a look.

It’s been a long time since I really discussed Cocoa programming on this weblog, and since Cocoal.icio.us is now open source, it seems germane to talk about some of the project’s code. I’m particularly fond of the simple bits of code that make life so much easier, and I think one of the best examples of this in Cocoal.icio.us is the “setAction:forKey:” and “actionForKey:” methods found in the SFHFTableView class.

These methods were written because I wanted to provide quick, arrow key navigation between views (the tag table and the posts table) along the lines of what NetNewsWire and Address Book do. I was somewhat surprised, however, to find that Cocoa has no generalized way of associating actions (selectors) with key events. Rather, subclassers must override NSResponder’s “keyDown:” method to detect key presses and create a big switch statement to associate particular keys with their appropriate actions.

Since I’m always a proponent of spending the extra time to solve a problem in the general case, I created an NSTableView subclass and implemented “setAction:forKey:,” which stores an association between a character and a selector in an NSDictionary instance variable. When the view’s “keyDown:” method is called, it queries “actionForKey,” which returns the selector specified for the given character, and if one exists, calls it (otherwise it simply passes the event on to the superclass’s “keyDown:”).

With this mechanism in place, the key actions for a view can be easily configured from outside the view itself, by placing lines like the following in the application delegate’s “awakeFromNib” method, for example:

[tagList setAction: @selector(makePostListFirstResponder) forKey: NSRightArrowFunctionKey];

There are a few things about this technique that are less than optimal in my opinion—it doesn’t take into account key modifiers (although I check [[NSApp currentEvent] modifierFlags] in my event handler to get around that) and it can’t be “injected” into NSResponder itself via a category since it requires an instance variable—but all in all, I think this way of doing things is a lot more elegant and Cocoa-like than the alternative.

As much as I’d like to, I can’t put all of the blame for my recent silence on email. Part of my problem is that I’m an inveterate taker-on of side projects, and one in particular has consumed a lot of my time recently: Cocoal.icio.us.

I felt particularly under the gun to get b22 of Cocoal.icio.us out the door, since it contains changes to make the app compatible with Joshua Schachter’s recent API changes and conformant to his best practices for future client development. To wit:

• I changed the code to use the new “/posts/all” API call instead of the much nastier “/posts/recent?count=10000” (which Joshua recently limited to return no more than 100 posts).
• I made the entire API URL prefix (instead of just the server name) configurable to more easily support Joshua’s plans for versioned API URLs (e.g. http://api.del.icio.us/1.0/api/etc).
• I changed the authentication code to store the password in a keychain item instead of the preferences. Aside from simply being the right thing to do from a security standpoint, this change was necessary because of the vagaries of how NSURLConnection handles HTTP authentication when doing a synchronous request. In that mode, the username and password either have to be specified as part of the requested URL (which has its own set of problems) or must already be in the keychain when an authentication challenge is received (in asynchronous mode, you simply get a delegate callback from which you can provide credentials).
• Since Joshua recently added an API call to delete posts, I exposed this functionality in the client.
• Since Joshua fixed the previously broken tag renaming API call, I re-enabled that functionality in the client.

The authentication rewrite is what took the most time, and, honestly, I still don’t have it working the way it should (I think I’ll try to do a Brent Simmons/Fraser Speirs-style extended discussion of the issues involved in another post).

After getting the more difficult changes out the door, I decided it would be fun to work on eye candy again, so I cranked out b23, which adds a feature aped from NewsFire: optional window transparency when the app goes inactive. This was a pretty easy feature to add (even the UI—have I mentioned that NSUserDefaultsController is the killer app of Cocoa Bindings?), and I kind of like having it since I tend to always keep Cocoal.icio.us open in the background.

As always, feedback and bug reports are welcome (don’t be scared off by my recent anti-email tirade—just don’t always expect an immediate response).

I used to think that Donald Knuth was merely a being a crotchety old academic when he famously swore off email in 1990. Now I know better: in fact, I think he was far ahead of the curve in realizing what an enemy of productivity (and sanity) email can be.

When I was given my first email address, back in college, I eagerly awaited new messages, compulsively checking Pine during any lull in CS lab activity. Now, between PodWorks support, Cocoal.icio.us feedback, communications with friends and family, mailing lists, electronic billing notifications, weblog comments, and other assorted communications, I’ve come to dread opening Mail (and that’s just my home account!). I currently have something like 50 flagged messages at the top of my inbox, going back to the beginning of the month. They’re all messages I was glad to get, and all are worthy of a reply, but I don’t know when I’m going to be able to get to them.

Why am I breaking my long weblog silence to tell you this? Two reasons: first, to explain part of the reason it’s been so quite around here (I used have a weblog, now I have email!); and second to plead for your patience if you have sent me a message that I haven’t replied to. I assure you that I consider your message important—it’s just that somtimes I need to sleep.