So, somewhere around the beginning of this month I was resting a bit from writing my book (which I’ve mentioned in passing here), and it struck me that the complaints about Leopard’s Stacks weren’t dying down – if anything, they were growing more numerous. I hadn’t really used Tiger’s Dock popup menus much, but I really thought someone would find out a way around it soon.

But when I searched – not too intensely at first – for such a solution, I found that the existing ones were really quite (searching for a charitable word here)… feeble. They all depended on something outside the Dock itself. And this struck me as what Apple likes to call a “third-party opportunity”.

So while I was testing out some sample code for the book, a few days later, I thought I could play around with it and find out what could be done with the Dock. I immediately noticed that putting a proxy icon in the Dock might be doable, and popping up a menu from there might be too. In a few days I had a primitive version of the menu itself working – I decided it had to be a background/foreground application pair.

Up to then I hadn’t put much time in but when I tried to do the foreground application I began hitting some snags. On November 10 – 20 days ago – I decided to throw everything I’d done so far away and start over from zero. Two days later I had a working alpha to show to some friends, and on Nov.15 I decided it was good enough for a public beta. It took a day to make the necessary changes to my site, prepare listings on the various software sites, write a press release and so forth.

Response to the first beta was so good I decided to keep at it full-time; I also figured that, now that people could see how it might be done, competitors would soon appear. Anyway, on Nov.27 – version 1.0 came out, and today, exact 20 days after restarting the project, 99% of known bugs are fixed in 1.0.1. (In case you’re curious, double-clicking still doesn’t work satisfactorily.) And I still haven’t heard of any full-featured competitor… yes, the principle is easy, but the details aren’t.

So far I’m quite satisfied with the responses. One thing I hadn’t foreseen was the number of people not content with popups – many also want to drag & drop files on the Dock folders. And this didn’t crop up in the complaints I read, because you can drop files on Stacks! But I rarely or never did that, so it was a surprise to me.

The problem is, to the current Dock, every type of item is handled differently. An application goes into the left side. Files and folders go into the right side; folders become Stacks, and can receive drops; files can’t. On the other hand, files can be clicked on – that is, the application that “owns” them is notified – but for folders, nothing happens. I tried various combinations of packages and bundles to get a folder that could be both clicked and dropped on, but no luck.

Compounding the difficulties was my resolution to “use no magic”. I knew this would be a powerful positive factor; users are tired of side effects caused by applications hacking the system. However, this meant that the Dock would never know I was doing something around its functionality, and, since there’s no public API to get information into and out of the Dock, I was quite restricted in what I could do.

I was also surprised that, despite my explaining all that on the product page, and repeatedly in response to questions in the support forum, people kept writing in with suggestions that showed that, for them, Quay did hack the Dock somehow – or even was a plugin for it. That’s the downside of when your technology “just works”: people’s mental models of what you’re doing can often diverge severely from reality.

Speaking of which, here’s my favorite review:

Just been playing with Quay. Rainer is a mad man. It takes true insanity to hack the dock without actually hacking the dock.

None of this would have been possible without Cocoa; I can’t imagine writing such a complex (internally, that is) pair of applications in anything else in 20 days. Many of the pieces – regarding registration and serial number handling, especially – came from my work on XRay II. Some of the icon and file handling routines were also adapted from there. The flipping “About” window is straight from my Flipr code; as soon as I find time, I’ll rewrite that for CoreAnimation.

Looking over the code today I was struck by the diversity. The main Quay app uses mostly NSWorkspace and NSFileManager, but then suddenly dips into Carbon to handle icons and some menu aspects. The background app (QuayMenu) uses mostly FSRefs and some BSD stuff for file handling, but it’s of course written in Cocoa, too.

A great side-effect of Cocoa is that, once your infrastructure is in place and coded properly, adding most new features is just a matter of a few lines; when it requires more, it shows that the original design wasn’t powerful enough. A good learning experience.