My son Dylan is away at college, and on January 27 — the day of the iPad announcement — I was on my way to visit him when I noticed that I was walking by the campus bookstore. I flashed back to January 24, 1984, when I was a freshman at the same college, and had eagerly hurried into that same bookstore to witness the unveiling of Apple's new Macintosh computer. On both days it felt as if the world of computers was being made anew.

The announcement of the iPad, and the recognition by some (e.g. Steven Frank, Frasier Spiers and Dan Moren) that this represents a new era of computing, gives me a powerful sensation of déjà vu. Like the iPad, the Macintosh that Apple unveiled in 1984 was intended to radically simplify computing. Jef Raskin, who started the Macintosh project at Apple, believed that personal computers should be more like appliances: simple, rather than complicated, focused on specific tasks, rather than general-purpose. Raskin left Apple in 1982, but the idea of computer-as-appliance lived on in the Macintosh. If you wanted to write, you put in your MacWrite floppy disk and it became a word processing machine. If you wanted to draw, you put in your MacPaint disk and it became a digital sketchpad. Every application took over the entire screen, and turned the machine into a specialized device. In that way it was not so different from the iPhone of today (or the iPad of this coming April).

Raskin went on to create an even more appliance-like computer, the Canon Cat, which was a commercial failure. And the Macintosh itself only barely escaped an early demise. While Apple had planned to sell millions, the first year’s sales did not reach 100,000, and it was only the fortuitous emergence of desktop publishing that saved the Mac from cancellation. Over time the Mac acquired new features and capabilities, and new complexity, such that today we can look at it as an example of “Old World” computing that we hope to move beyond.

For the iPad to truly usher in a new age of user-centric computing it needs to succeed commercially, and it needs to avoid the creeping complexity that turned the 128k Mac into the MacBook Pro of today. There are reasons for optimism on both scores. Past efforts — the Mac, the Cat, and the Newton — tried to build a new world from scratch, offering no compatibility with existing platforms. As John Gruber has persuasively argued, it was that incompatibility more than anything else that doomed the Mac to its small market share. It is simply too difficult to sell a computer that forces consumers to throw away everything they have learned and done before. The iPad does not have this weakness: it builds on the iPhone, which in turn built on the iPod and iLife and Safari and Mac OS X, which in turn built on the classic Mac OS and NeXTSTEP. The Mac started with three applications (MacWrite, MacPaint, and Multiplan); the iPad will start with over 100,000. The iPad, like the iPhone, also starts with the web, the most critical and adaptable “application” of all.

The iPad will therefore not succumb to the usual new platform Catch-22 of having neither enough market share to attract software, nor enough software to build market share. But will Apple resist the temptation to add new features until an iPad requires as much training and expertise as a general-purpose personal computer? It’s much too early to tell, but the design decisions Apple has made to date suggest an encouraging restraint. They are helped by the fact that the iPhone and iPad can be huge successes without trying to be all things to all users. Customers who need a more flexible and complicated device can buy one, but most will be perfectly happy with an iPad. As new uses and technologies become mainstream Apple can incorporate them, while ensuring that the simplicity and usability of the platform is protected.

As a developer I have mixed feelings about this incipient new age. I remember when the U.S. telecommunications system was run by a benevolent monopoly, with awesome reliability and ease of use, and equally awesome resistance to change. Ma Bell imposed a narrow bottleneck for technological progress, a bottleneck that was ultimately smashed by the anarchic personal computer market. It was the wide-open personal computer that let hobbyist developers write and sell BBS systems, PPP drivers, and ultimately web browsers — without having to first ask permission. It is not difficult to imagine some great new idea dying because it can’t get through the App Store, or because the developer decides it is not even worth trying.

That said, I fervently hope that the iPad does represent a new world for computers. We developers build things to help people, but it is all too easy to focus on the things rather than the people. Today’s computers are wonderful, but they aren’t good enough for people. The iPad is another chance to do better.

I read a lot of articles online, and sometimes the ads and navigation links make it difficult to concentrate on the text of article, much less on the ideas that the text is trying to communicate. The folks at arc90 have come to the rescue with Readability, a JavaScript bookmarklet that reformats the current web page as a clean page of text:

→

Readability works great in Safari, but I do most of my web reading in NetNewsWire, the RSS reader by Brent Simmons of Newsgator. And NetNewsWire does not have a bookmarks bar where I could put the Readability bookmarklet.

Fortunately, NetNewsWire does have a Scriptmenu, and support for the do JavaScript AppleScript command. That makes it possible to add Readability support to NetNewsWire by following these steps:

1. Run Script Editor and create an AppleScript like the following:

   set theJS to "bookmarklet link"
   set jsScheme to "javascript:"
   if (offset of jsScheme in theJS) is 1 then
   	set theJS to (characters from (1 + (length of jsScheme)) to -1 of theJS) as string
   end if
   tell application "NetNewsWire"
   	do JavaScript theJS
   end tell
   

2. Go to the Readability web page to create a bookmarklet with your preferred settings
3. Right-click (or Control-click) the bookmark and choose Copy Link
4. Back in Script Editor, paste the link you just copied in place of the text bookmarklet link; it will start with "javascript:" and will be quite long
5. Save your script (e.g. to the Desktop)
6. Choose Open Scripts Folder from the Scriptmenu in NetNewsWire
7. Copy your saved script to the NetNewsWire Scripts folder

Once you’ve followed these steps your script will be listed in NetNewsWire’s Scriptmenu, and you can choose it to invoke Readability for the currently displayed web page.

I am a fan of the writer Tracy Kidder (The Soul of a New Machine, House) and a few years ago I picked up his then-latest book, Mountains Beyond Mountains. It tells the story of a doctor, Paul Farmer, who (along with friends Ophelia Dahl and Jim Yong Kim) created an organization called Partners In Health. PIH was founded to deliver high quality health care to the people of Haiti’s Central Plateau. Working with the people of Haiti, PIH’s efforts there have grown from a single clinic in 1985 to a system of hospitals, clinics, and community health workers that provided 2.6 million patient visits in 2009, all of them free of charge. It is a moving and inspiring story that convinced me to become a financial supporter of PIH’s work.

In the aftermath of the earthquake that struck Port-au-Prince on January 12, 2010, Partners In Health is perhaps the largest functioning medical provider left in Haiti. Their own facilities are far enough from the epicenter to have escaped serious damage, and their trained medical teams have been working around the clock to treat survivors. If they can afford to purchase the supplies they need, they will be able to save thousands of lives, not only from earthquake injuries, but also from the infections and other public health threats that will emerge in the weeks and months ahead.

To help make that happen, Fetch Softworks is one of nearly 150 independent Mac and iPhone developers participating in Indie+Relief, a group fundraiser for Haiti. If you purchase a Fetch 5.5 license on Wednesday, January 20, 2010, 100% of the proceeds will be donated to Partners In Health. If you already have a Fetch license, please take a look at the other applications that are for sale: you can pick up a great app and help Haiti at the same time. And if you do not need any software, please visit the PIH website, learn more about their work, make a donation, and spread the word.

Many thanks to Justin Williams of Second Gear Software for organizing Indie+Relief.

UPDATE: Thank you to everyone who purchased Fetch 5.5 yesterday — you raised $3,742 for Partners In Health!

Hello from Italy!

While my Fetch colleagues are toiling away at their posts, I am taking a break from Fetch to have an adventure. I am one of ten developers from around the world gathered together in Venice, Italy by Command Guru to develop an iPhone app from scratch in seven days. If that were not enough, the entire experience is being streamed live at commandguru.com.

So if you ever wondered what goes on behind the scenes to produce the apps you use, you can tune in to watch us sketch, discuss, argue, and type our way to actual software. We have been at it for three days now, and it’s been great fun to work with this terrific group of developers, and to get instant feedback from viewers around the globe. Not to mention all the fantastic Italian food!

In honor of this unlikely event we’re offering an equally improbable promotion: a Fetch half-off sale. Today and tomorrow, December 10 and 11, 2009, you can get a 50% discount on Fetch by entering the coupon code COMMANDGURU.

Ciao!

The default behavior of Subversion when tunneled over SSH works well for simple cases. I encountered some more complex situations which required digging into advanced SSH features, and built some simple tools that make our Subversion life easier.

Specifying a username for SSH repositories

By default, when you connect to a Subversion repository over SSH, Subversion will assume that the remote username is the same as the local username. When this is not true, you can force a different username to be used. When you check out the repository, use:

svn checkout svn+ssh://svn-username@svn-hostname/svn-path

Subversion will parse the username out of the URL, and pass it through to SSH, which will then prompt you for the password for the correct account.

Avoiding multiple password prompts

If you have a simple SSH repository, you will be asked for your password once at the beginning of a Subversion command. However, if your repository contains externals, you will be asked for your password again for each external that requires it. If you have multiple externals on the same server, you get to enter the same password multiple times.

To work around this you can use SSH session sharing. Session sharing lets multiple SSH connections to the same server share a single network connection. That also causes multiple SSH connections to the same server to share credentials, and therefore you don’t have to reenter your passwords during a single Subversion command.

To set up SSH session sharing, you need to add this to your ~/.ssh/config:

ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

To verify that it works, open an SSH connection in Terminal, then open a new Terminal window and open another SSH connection to the same account as the first one. The second will not ask for your password.

The configuration above enables SSH connection sharing for all SSH connections. If, instead, you want to only enable connection sharing for your Subversion server, put the following at the bottom of your ~/.ssh/config:

Host svn-hostname
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

Avoiding multiple password prompts — the pair.com users’ version

On pair.com — I imagine this may also be true of some other hosting providers — the above recipe with SSH session sharing works great as long as your repository has fewer than ten externals. Once you get to ten externals, you see a “channel 10: open failed” message and your Subversion command dies.

This is because pair.com limits SSH session sharing to ten simultaneous connections to a given server. Unfortunately, Subversion keeps every SSH connection open until it’s done with all of them. If you have ten externals on the same server, you wind up with eleven simultaneous SSH connections (ten for the externals and one for the root of the repository), and so your SSH and Subversion error out.

The good news is that SSH already has a mechanism to delegate its password prompting to another tool (this is what programs like Fetch use to give a graphical user interface for entering your SFTP password). If you had a tool that handled SSH password prompting, but was also capable of remembering the passwords you gave it and not asking you to reenter them, you would only get asked for your password once.

An SSH password prompter is relaunched for every prompt, so it needs a place to stash passwords during a single Subversion command. An easy way to handle this is to write a tool which creates a password store and then launches Subversion. Using that tool instead of Subversion will provide the password prompter with the password repository it needs to work correctly.

This is what the Subversion replacement looks like:

#!/usr/local/bin/python

from __future__ import with_statement
from subprocess import call
from tempfile import mkdtemp
from os import mkfifo, environ
from os.path import join, expanduser
from sys import argv
from threading import Thread
from pickle import load, dump
from getpass import getpass

request_pipe_path = join(mkdtemp(), "svn-askpass-requests")
response_pipe_path = join(mkdtemp(), "svn-askpass-responses")

mkfifo(request_pipe_path)
mkfifo(response_pipe_path)

args = argv[1:]

def prompt_loop():
    cache = {}

    while True:
        with open(request_pipe_path, "r") as request_pipe:
            hidden, request = load(request_pipe)

        if not request in cache:
            if hidden:
                cache[request] = getpass(request)
            else:
                cache[request] = raw_input(request)
            
        with open(response_pipe_path, "w") as response_pipe:
            dump(cache[request], response_pipe)
            
prompter = Thread(target=prompt_loop)
prompter.daemon = True

environ["SSH_ASKPASS"] = expanduser("~/.subversion/svn-ssh-askpass")
environ["SSH_ASKPASS_REQUEST_PIPE"] = request_pipe_path
environ["SSH_ASKPASS_RESPONSE_PIPE"] = response_pipe_path

prompter.start()

exit(call(["/usr/local/bin/svn"] + args))

There isn’t much to it — it creates two pipes, on one of which it reads prompts and on the other of which it provides user responses. Before starting Subversion, it spawns a background thread, from which it listens for prompts. If it receives a prompt that it has already seen, it returns the same answer as before; if it receives a prompt it hasn’t already seen, it presents it to the user and stores the answer for later.

If you weren’t familiar with them before, you may find these interesting:

• tempfile.mkdtemp: securely creates a temporary directory readable only by its owner
• getpass.getpass: securely prompts for a password
• threading.Thread.daemon: if set on a thread, then the thread is automatically killed off when all other threads are done
• os.path.expanduser: expands ∼ to user’s home path
• os.environ["SSH_ASKPASS"]: the way to tell SSH to delegate password prompting

This Subversion wrapper sets up SSH to use ~/.subversion/svn-ssh-askpass for password prompting. However, SSH doesn't use the value of SSH_ASKPASS unless a few specific conditions are met, and those conditions are not met when Subversion command line invokes SSH. Therefore, we also need to create a wrapper for SSH, which will set things up so that password prompting is delegated to the prompter, and then we need to tell Subversion to invoke that SSH wrapper instead of SSH.

This is what the wrapper looks like:

#!/usr/local/bin/python
from os import setsid, environ
from subprocess import call
from sys import argv

# We have to invoke SSH from a process with no controlling terminal
# in order to get SSH_ASKPASS to work
setsid()
environ["DISPLAY"] = "0"

exit(call(["/usr/bin/ssh"] + argv[1:]))

If you don’t really get all the details of this, that’s OK. I don’t either; it’s Soviet-era UNIX programming, I just Googled until I pieced it together.

Save that at ~/.subversion/svn-ssh-detach and tell Subversion to use this SSH wrapper by adding this to your ~/.subversion/config:

[tunnels]
ssh = /Users/ben/.subversion/svn-ssh-detach

Sadly, Subversion doesn’t expand ~ in tunnel configuration, so you have to put the full path to your home there.

OK, now we have a Subversion wrapper that can cache passwords, and we have an SSH wrapper that can delegate its password prompting to a custom prompter. All we need to do to close the loop is write a custom prompter that talks to the Subversion wrapper instead of directly prompting you:

#!/usr/local/bin/python

from __future__ import with_statement
from sys import argv
from os import environ
from pickle import load, dump

prompt = argv[1]
secret = False

if "password:" in prompt:
	secret = True

with open(environ["SSH_ASKPASS_REQUEST_PIPE"], "w") as request_pipe:
	dump((secret, prompt), request_pipe)

with open(environ["SSH_ASKPASS_RESPONSE_PIPE"], "r") as response_pipe:
	print load(response_pipe)

And there you have it. To recap:

• Subversion wrapper: put it anywhere you like, make sure it’s executable
• Subversion configuration changes: put them in ~/.subversion/config
• SSH wrapper: put it in ~/.subversion/svn-ssh-detach, make sure it’s executable
• SSH prompter: put it in ~/.subversion/svn-ssh-askpass, make sure it’s executable

From there on, invoke your Subversion wrapper instead of svn (or create an alias that runs the wrapper when you type svn).

Fetch 5.5.3, a bug-fix update to Fetch 5.5, is now available. This release fixes a number of problems reported by our users.

The changes in Fetch 5.5.3 include:

• Fixed Mac OS -8905 errors when opening Fetch or saving shortcuts on Mac OS X 10.6 Snow Leopard
• Fixed rare freezes when quitting
• Fixed a problem where Fetch displayed the copy cursor when moving a file
• Fixed problem displaying file lists with Norwegian month names from vsFTPd servers
• Fixed a problem where items moved to a parent folder would sometimes not appear in the parent folder's file list
• Improved compatibility with certain versions of the VanDyke VShell server that send non-standard TYPE replies

For a complete list of changes, see the Fetch 5.5.3 Release Notes.

The Fetch 5.5.3 update is free if you purchased your Fetch license after January 28, 2009; otherwise an upgrade is $10, and a new license is $29.

Please download Fetch 5.5.3 from the Fetch Download page, or by choosing Check for Update… from the Fetch menu in an earlier version, and let us know what you think of the new release.

Fetch 5.5.3 is a Universal binary, compatible with Mac OS X 10.3.9 or later, including Mac OS X 10.5 Leopard and Mac OS X 10.6 Snow Leopard.

Upgrading an application can be an annoying process. In the best case, you click an Upgrade button and go on with your work; in the worst case, you spend hours in frustration trying to make the new version work. For some applications — such as Fetch — the upgrade experience is made simpler by code signing, a Mac OS X 10.5 Leopard technology.

From the earliest days of Mac OS X, Apple made it easy to securely store passwords in the keychain. A password in the keychain no longer has to be remembered, making it easy for you to log into different accounts, websites, and servers.

An application can only see those passwords that you let it see. The first time an application tries to access a password saved by another application, you have to give it permission. For example, without your permission, Fetch can’t access your bank account password, and Safari can’t access your Fetch passwords.

Before Mac OS X 10.5, every time you upgraded an application, you had to re-approve it for password access. A new version of Fetch would need to get your permission to access your web host password, even though the old version of Fetch already had that permission.

This was because there was no way for Mac OS X to tell a new version from a fake. The fear was not that a new version of Fetch would steal your passwords, but that someone would fool you into installing a Fetch lookalike that emails all your passwords to a miscreant.

Requiring new versions to ask for permissions was a safe thing to do, but it made it rather tedious to upgrade some applications. After you installed a new version, the first time you tried to access a password-protected account, you would see something like this:

“Huh?” you’d say. Change All sounds ominous, given that you were probably just logging in and not yet trying to change anything, but good luck figuring out from that dialog if this was change you could believe in.

Of course, if you click Don’t Change, you’ll get the same question next time. Your computer is giving you a not-so-subtle hint: if you want to get on with your life, you might want to click Change All, whatever in the world that means.

To make matters worse, you wouldn’t always get the same dialog; depending on how you upgraded, you may see a completely different dialog. Even worse, sometimes you might see the dialog once for each password… every time you upgrade.

All in all, this made upgrading confusing and annoying. Nobody was happy about this state of affairs, and, starting with Mac OS X 10.5 Leopard — released in 2007 — Apple made it possible for developers to give the Change All mole one final whack. Using a technology called code signing, information about who created an application can be stored inside the application in a way that can’t be tampered with or falsified.

Once an application contains its author’s identity, Mac OS X can tell the difference between a new version of an application (which has the same author identity as the old version) and a fake (which would have someone else’s identity, or no identity at all). This way, Mac OS X can give new versions of Fetch access to all the passwords that older versions of Fetch had access to. At the end of the day, this is one less reason for having to sweet-talk your computer into letting you get work done.

This is so obviously good for our users that we ran off to sign Fetch two years ago, when we were working on Fetch 5.3, aiming to release it concurrently with Mac OS X 10.5. To gain some other benefits of code signing, we needed to obtain an official code-signing certificate™, issued by an official certificate authority™.

We applied for a certificate, and the issuer conscientiously asked for all sorts of information about the company. Nothing too complicated — company name, company address, a proof that we are a legitimate business, and so on.

This is when we somewhat unexpectedly found out that, while we were busy shipping software, our company ceased to be. Our corporate registration with the New Hampshire Secretary of State had lapsed; before we could proceed, we had to have our status as a legitimate business reinstated. Several months and layers of red tape later, we finally got our hands on a certificate, but by now it was much too late to sign Fetch 5.3 — as planned, we had released it shortly after Mac OS X 10.5 came out.

We signed the next version — Fetch 5.3.1, released in March 2009. Since then, we have been delivering you features and bug fixes without the pesky keychain approval alerts. Enjoy!

Since the day Snow Leopard came out, much has been said about creator codes, preferred applications, and Universal Type Identifiers. Regardless of whether you favor the Leopard behavior — in which a Mac OS 9-style creator code trumps a file‘s extension — or the Snow Leopard behavior — in which a Mac OS 9-style creator code is completely ignored — you, as a developer, may run into a case when you need to make sure that a particular file will open with a particular app when the user double-clicks it in the Finder.

We had the same need in Fetch; we allow Fetch users to specify which app a downloaded file will open with, because users sometimes want a downloaded file to open with a different application from a locally created file of the same type.

The general idea is to add a ‘usro’ resource with ID 0 to the file. This will take you about ten lines of code — then you will spend the next hundred lines of code doing things that make it all work well for the user.

void
FileRef::SetApplication(
  const string& inIdentifier,
  U::ApplicationRef inApplication)
{

This function takes two arguments (besides the implicit this, which represents the file you are changing): the Universal Type Identifier for the file’s type (such as ‘public.html’), and a reference to the application you want the file to open with.

An U::ApplicationRef is our wrapper around application bundles. It provides helpers for looking up bundle IDs, finding apps from a bundle ID, etc. Similarly, a FileRef is our wrapper around a Carbon FSRef. I am not including code for such wrappers here; they’s self-explanatory.

First, clean up any existing ‘usro’ resource in the file:

string path = inApplication.GetFile()->GetPath();
// Put a usro(0) resource in 
U::ResourceFileRef resFile(*this, fsRdWrPerm);
::Handle oldUsro = ::Get1Resource('usro', 0);
if (oldUsro) {
  ::RemoveResource(oldUsro);
}

Next, create a new ‘usro’ resource and add it to the file:

// Must be 1028 bytes long or Tiger freaks out
Handle newUsro(::NewHandleClear(PATH_MAX + sizeof(UInt32)));
if (path.length() > PATH_MAX - 1) {
  path.erase(path.begin() + PATH_MAX - 1, path.end());
}

**reinterpret_cast<UInt32**>(newUsro.Get()) = path.length();
copy(
  path.begin(), path.end(), 
  *reinterpret_cast<char**>(newUsro.Get()) + sizeof(UInt32)
);

::AddResource(newUsro.Get(), 'usro', 0, "\p");
ThrowIfResourceError();
newUsro.Abandon();

I think what that comment is trying to tell me is that Launch Services in some versions of Mac OS X 10.4 Tiger did not recognize a ‘usro’ resource unless it was exactly 1028 bytes long. Aside from that, this snippet contains the most salient information about the ‘usro’ resource: its first four bytes contain the length of the filesystem path to the application which will open when the file is double-clicked; the remaining 1024 bytes contain the path itself.

It’s rather interesting that we aren’t doing anything to make the 4 bytes of length at the front of the resource be of any particular endianness. According to our version history, this code predates the PPC-Intel transition, and therefore I can only assume that it used to work on PPC computers as well as it works on Intel computers today. This suggests that copying a file from a PPC computer to an Intel computer might render its ‘usro’ resource useless, depending on whether Launch Services knows to interpret ‘usro’ resources with non-native endianness.

If all you are looking for is a file that opens in the given app when double-clicked, you are all set. However, your users will probably be confused because the file’s icon will not reflect its new affiliation — you might now have a text file that opens in BBEdit, but the Finder will continue to show it with its default icon, which probably belongs to TextEdit. It would be nice to do something about that.

The app’s info dictionary holds information about which icon should be used:

// Track down the custom icon we should use for this file
string extension = GetFileNameExtension(this->GetName());

optional<string> iconFile;
U::CFDictionaryRef appInfo = inApplication.GetInfoDictionary();

// If the app has no info dictionary, it is probably an old Carbon or
// Classic app and may require the file creator to be set, so we set it
if (not appInfo) {
  this->SetCreatorAndType(inApplication.GetSignature(), this->GetType());
} else {
  this->SetCreatorAndType(kLSUnknownCreator, kLSUnknownType);
}

You may be inclined to summarily ignore old apps that don't have an info dictionary. If your customer support sometimes feels like archeology, you probably want to keep that section of the code.

Finally, extract the icons:

if (appInfo) {
  iconFile = IconFileInAppForType(appInfo, inIdentifier);
  if (not iconFile) {
     iconFile = IconFileInAppForExtension(appInfo, extension);
  }
}

I’ll elaborate on IconFileInAppForType and IconFileInAppForExtension later; for now, just assume you found the icon file name.

// Load the custom icon from app's resources or fall back on default
IconFamilyHandle iconFamily = 0;

if (iconFile) {
  // If the app is a bundle, use CFBundle to get at the icon
  if (not inApplication.GetFile()->IsFile()) {
    U::CFURLRef appURL(U::CFAdopt(::CFURLCreateFromFSRef(
      kCFAllocatorDefault,
      &inApplication.GetFile()->Get()
    )));
    
    U::CFURLRef icon = U::CFAdopt(::CFBundleCopyResourceURLInDirectory(
      appURL.get(),
      lexical_cast<U::CFStringRef>(iconFile.get()).get(),
      CFSTR("icns"),
      0
    ));

    // Try without extension if we can't find it with extension
    if (not icon) {
      icon = U::CFAdopt(::CFBundleCopyResourceURLInDirectory(
        appURL.get(),
        lexical_cast<U::CFStringRef>(iconFile.get()).get(),
        0,
        0
      ));
    }
    
    if (icon) {
      FSRef iconFile;
      if (::CFURLGetFSRef(icon.get(), &iconFile)) {
        ::ReadIconFromFSRef(&iconFile, &iconFamily);
      }
    }
  } else {
    SInt16 resID = lexical_cast<SInt16>(*iconFile);

    U::ResourceFileRef appResFile(*inApplication.GetFile(), fsRdPerm);
    
    // Try icns resource first
    iconFamily = reinterpret_cast<IconFamilyHandle>(
      ::Get1Resource(kIconFamilyType, resID)
    );
    if (iconFamily) {
      ::DetachResource(reinterpret_cast< ::Handle(iconFamily));
    }
    // Otherwise, use icon suite resources
    else {
      IconSuiteRef iconSuite = 0;
      ThrowIfOSError(::GetIconSuite(
        &iconSuite, resID, 
        kSelectorAllAvailableData
      ));
      ::IconSuiteToIconFamily(
        iconSuite, kSelectorAllAvailableData, 
        &iconFamily
      );
      ::DisposeIconSuite(iconSuite, true);
    }
  }
}

What just happened here? First off, an IconFamilyHandle is the Carbon way of representing the collection of several different resolutions of the same icon. I don’t know if there’s a newfangled way of managing those, without getting tangled in APIs from the last millennium, so IconFamilyHandle it is.

Second, an app might be a bundle (a maze of twisty little files and directories), or it might be a monolithic file (a maze of twisty little resources).

If it’s a bundle, then the icon filename you got earlier refers to an icon file somewhere inside the bundle — which CFBundle APIs will happily hand over to you. Except when they won’t, because some developers put the complete icon filename (including the extension) in their info dictionary, and some omit the extension, letting the OS tack on ‘icns’ as needed. Therefore, you need to look for the icon in two places.

If the app is not a bundle, then the icon filename you got from the info dictionary is not a filename at all — it’s a resource ID. It might refer to a single ‘icns’ resource (in modern apps) or it might be a collection of individual resources (of which there are approximately zillion, with such prosaic names as ‘t8mk’ and ‘ics#’). If you are looking at a single ‘icns’ resource, then a simple Get1Resource will fetch it. Otherwise, to load the myriad different separate resources, use GetIconSuite, and then convert the result to an icon family.

There's also the case when you find no icon at all — it’s better to give the document a generic icon (which will leave the user uninformed about which app will open the document) than leave it with no custom icon (which will probably suggest that the file will open in some app other than the one you just set it to open with):

if (not iconFamily) {
  static U::Icon genericIcon = U::Icon::FromTypeCreator(
    kSystemIconsCreator, kGenericDocumentIcon
  );
  ThrowIfOSError(::IconRefToIconFamily(
    genericIcon.Get(), kSelectorAllAvailableData, 
    &iconFamily
  ));
}

Alright! Now you have the icon. Remove the old icon, write the new one to the file, and let the Finder know that the file has a custom icon:

U::Handle newIcon(reinterpret_cast< ::Handle>(iconFamily));

// Put a custom icon resource in
::Handle oldIcon = ::Get1Resource(kIconFamilyType, kCustomIconResource);
if (oldIcon) {
  ::RemoveResource(oldIcon);
}

::AddResource(newIcon.Get(), kIconFamilyType, kCustomIconResource, "\p");
ThrowIfResourceError();
::SetResInfo(newIcon.Get(), kCustomIconResource, "\pBinding Override");
ThrowIfResourceError();
newIcon.Abandon();

// Set the custom icon flag
FSCatalogInfo info;
ThrowIfOSError(::FSGetCatalogInfo(
  &this->Get(), kFSCatInfoFinderInfo, 
  &info, 0, 0, 0
));
FileInfo& finderInfo = *reinterpret_cast<FileInfo*>(&info.finderInfo);
finderInfo.finderFlags |= kHasCustomIcon;
ThrowIfOSError(::FSSetCatalogInfo(&this->Get(), kFSCatInfoFinderInfo, &info));

And now you are done. Oh, wait… maybe some day you will want to undo this, and let the file open with its default application:

void
FileRef::ResetApplication()
{
  // Remove usro(0) resource, icns(-16455), and clear the custom icon bit
  U::ResourceFileRef resFile(*this, fsRdWrPerm);
  ::Handle oldUsro = ::Get1Resource('usro', 0);
  if (oldUsro) {
    ::RemoveResource(oldUsro);
  }
  ::Handle oldIcons = ::Get1Resource(kIconFamilyType, kCustomIconResource);
  if (oldIcons) {
    ::RemoveResource(oldIcons);
  }

  FSCatalogInfo info;
  ThrowIfOSError(::FSGetCatalogInfo(&this->Get(), kFSCatInfoFinderInfo, &info, 0, 0, 0));
  FileInfo& finderInfo = *reinterpret_cast<FileInfo*>(&info.finderInfo);
  finderInfo.finderFlags &= ~kHasCustomIcon;
  ThrowIfOSError(::FSSetCatalogInfo(&this->Get(), kFSCatInfoFinderInfo, &info));
}

If you made it this far, I suppose you probably want to know how to get the icon file name from an app’s info dictionary. It’s a simple matter of looking things up in CFBundleDocumentTypes (for apps that haven't adopted UTIs yet) or LSItemContentTypes (for those that have).

optional<string>
IconFileInAppForExtension(
  U::CFDictionaryRef inAppInfo,
  const std::string& inExtension)
{
  return IconFileInAppForKeyValue(
    inAppInfo, 
    CFSTR("CFBundleTypeExtensions"), inExtension
  );
}

optional<string>
IconFileInAppForType(
  U::CFDictionaryRef inAppInfo,
  const std::string& inExtension)
{
  return IconFileInAppForKeyValue(
    inAppInfo, 
    CFSTR("LSItemContentTypes"), inExtension
  );
}

optional<string>
IconFileInAppForKeyValue(
  U::CFDictionaryRef inAppInfo,
  CFStringRef inKey,
  const std::string& inValue)
{
  U::CFArrayRef docTypes = cf_cast<U::CFArrayRef>(::CFDictionaryGetValue(
    inAppInfo.get(), CFSTR("CFBundleDocumentTypes")
  ));

  if (docTypes) {
    U::CFStringRef valueStr = lexical_cast<U::CFStringRef>(inValue);
    
    for (
      CFIndex i = 0;
      i < ::CFArrayGetCount(docTypes.get());
      ++i
    ) {
      U::CFDictionaryRef docType = cf_cast<U::CFDictionaryRef>(
        ::CFArrayGetValueAtIndex(docTypes.get(), i)
      );

      U::CFArrayRef values = cf_cast<U::CFArrayRef>(
        ::CFDictionaryGetValue(docType.get(), inKey)
      );
      if (values) {
        for (
          CFIndex j = 0;
          j < ::CFArrayGetCount(values.get());
          ++j
        ) {
          U::CFStringRef appValue = cf_cast<U::CFStringRef>(
            ::CFArrayGetValueAtIndex(values.get(), j)
          );
          if (
            ::CFStringCompare(
              appValue.get(), valueStr.get(), 
              kCFCompareCaseInsensitive
            ) == kCFCompareEqualTo
          ) {
            U::CFStringRef iconFileName = cf_cast<U::CFStringRef>(
              ::CFDictionaryGetValue(docType.get(), CFSTR("CFBundleTypeIconFile"))
            );
            if (iconFileName) {
              return optional<string>(lexical_cast<string>(iconFileName));
            }
          }
        }
      }
    }
  }
  return optional<string>();
}

Of course, if you are only ever going to use this code to set the creator of a file to an application that you control, then you can skip most of the backwards compatibility cases. You won’t need the code for resource-fork based apps or apps without info dictionaries, and probably not even for apps that don’t use UTIs.

Fetch Softworks is pleased to announce Fetch 5.5.2, the latest version of the original Macintosh file transfer program. Fetch 5.5.2 has been updated to offer full compatibility with the newly released Mac OS X 10.6 Snow Leopard.

This release improves the Quick Look feature introduced in Fetch 5, and adds two new features: a "View as Text" command and SOCKS support for SFTP connections.

Fetch 5.5.2 is a Universal binary, compatible with Mac OS X 10.3.9 or later, including Mac OS X 10.5 Leopard and Mac OS X 10.6 Snow Leopard, and can be downloaded from http://fetchsoftworks.com.

Fetch 5.5.2 is free to try for 15 days, and a single-user license is $29. Upgrades are free for customers who purchased Fetch after January 28, 2009; otherwise, upgrades are $10. Free licenses and upgrades are available for educational and charitable use.

This is part 7 in a series on the redesign of fetchsoftworks.com; the series starts at Part 1: My Original Sin.

What Have We Done?

Now that the new website is up, I can sit back and appreciate the number of improvements. The design and typography are no longer embarrassing; they’re actually quite attractive. Every page has a search box, that in turn quickly searches every page, making our content immediately findable in a way it never was before. The new message board lets you post comments, monitor followups by email and/or RSS, and go back and edit your comments; all without forcing you to pick and remember a username and password. Underneath this all is a solid foundation of standard-based XHTML markup and CSS style, so that we could change the color of the entire site by editing a couple files. This last one is of interest mostly to us, but the rest are aimed at the site’s visitors, the customers we are trying to serve.

Those are the big things. But I love the little things just as much, perhaps because they are little:

• The s-t ligature on Fetch pages
• The little dog in the horizontal rule
• The way the shipping address fields collapse when you click the “Shipping Address is the same as Billing Address” checkbox
• The way the upgrade form figures out whether you are entitled to a free license, or how much the upgrade will cost, and just does the right thing
• The message board captcha that not only presents an obstacle to spambots, but also teases them a bit in the process
• No matter what URL you type to get to the site — http://www.fetchsoftworks.com, http://fetchworks.com, even http://fetch.net — your browser will show the canonical URL, http://fetchsoftworks.com

• The URLs (with a few exceptions) aren’t ugly things like

  http://fetchsoftworks.com/cgi-bin/Ultimate.cgi?action=intro&BypassCookie=true

  or even

  http://fetchsoftworks.com/Licensing/edustore.application.html

  Instead, they’re clear, extension-less, beautiful things like

  http://fetchsoftworks.com/fetch/messageboard

  and

  http://fetchsoftworks.com/fetch/free

• The way a different testimonial appears each day you visit the Fetch product page (did anyone ever bother to read the whole list of them on the old site?)
• The silly Star Wars joke (no link, I’ll let you find that one yourself) that came out of a long discussion on finding a better way to write “For more help see Online Help”

We have a long wishlist of things we still want to change or improve. You might think it’s wrong to have one form for purchasing with a credit card, and a similar-but-slightly-different form for purchasing with a check or PO. We do too! But for the first time in the company’s history, we have good place to work from.

So Who Are We Anyway?

I started with the idea that we could redesign our website in 6 months. It took over two years. We learned a lot of PHP, XHTML and CSS in that time, and we also learned about ourselves. We learned anew that we are picky, at least about the project that is in front of us. We could go 8 years with an ugly mess of a website, but once we were working on it we couldn’t let a URL end with “.php”. We put in untold hours of customization and testing to save our users the 30 seconds it takes to pick a message board username and password. Once we get started, we can’t seem to help ourselves, even if it means neglecting other possible priorities.

I think we also learned that we have more to say than we’ve been in the habit of saying. Our old site could go months between updates, not because we were on vacation — code was being written, customers were being supported, the message board was buzzing — but because we weren’t in the habit of telling the world what we were up to, and did not have an attractive platform to speak from. The new site takes care of the second count, and pushes us on the first. By putting our news and blog content on the home page we are daring ourselves to keep them fresh. We aren’t a company that talks about ourselves or our products much, but maybe we can be. We are about to find out.

Credits and Thanks

Our thanks to Robin Olson, who first talked to us about our visual identity, and to Leah McManus who helped us get started. Thanks also to Joe Finocchario, and the Happy Cog Philadelphia crew — Greg Hoy, Robert Jolly, Chris Cashdollar, Dan Mall, Heather Shaw, Jenn Lukas, and Dave DeRuchie. My personal thanks to my colleagues Ben Artin and Scott McGuire, for reviewing (and improving) these posts, and for all the thought and care and effort they put into the redesign.