A Trifle Absurd

Hacking Camino into GMail.app

Inspired by Michael McCracken’s Webmail.app, I came up with a way to turn a copy of Camino 1.1 Beta into a dedicated Gmail-reading application. Here’s how to do it (assuming you’re used to messing about inside an application package):

Make a copy of Camino.app, and rename it Gmail.app. Change the icon to something appropriate. Open up the application package, and drill down into Contents. In the MacOS folder, rename Camino to Gmail.

Then open up Info.plist. Change CFBundleExecutable, CFBundleName, and mozProfileDirName to “Gmail”. Change CFBundleIdentifier to something different (but in the same reverse-domain-name format). Save and close.

And that’s it. You now have a separate application you can use just for Gmail. Hide the bookmark bar and collapse the toolbar and you have a simple, clean window.

Well, almost. The status bar is still there, and Camino doesn’t provide a way to hide it. But you can get rid of it: open the Gmail.app package again and go to Contents/Resources/English.lproj. Load up BrowserWindow.nib in Interface Builder and simply delete the status bar controls.

Of course, there’s nothing particular to Gmail about all this — you could use the same technique to make a specialized browser app for anything.

Learning Takes Time

I often feel that Trifle is progressing at a snail’s pace. Shouldn’t I have gotten more done by now? But in my clearer moments I remember that I’m not just developing an app, I’m learning a new platform (Mac OS X), framework (Cocoa), and language (Objective-C).

Learning takes time. There’s no getting around it. I’m not just talking about the direct time it takes to learn something, but also the false starts and fruitless investigations that go along with it.

Last week I thought up a couple of different ways to handle custom columns in Trifle. I picked a solution and spent several days coding it. This week I realized that it was the wrong choice; the other way would be simpler and easier. So I had to rip out the work I’d done and start over.

Or take Core Data. Trifle is an awfully database-ish app, so I had to investigate whether Core Data made sense for it. I’ve learned quite a bit about Core Data now, in multiple stints, but it still isn’t the right choice for Trifle.

I could call that wasted time, but it isn’t, really. It’s just part of the overhead of learning to operate in a new environment. Besides, learning is one of my favorite things to do. Maybe that’s what attracted me to programming in the first place: there’s always something new to learn.

I (Still) Want an Editor

I want a Mac-native text editor that supports:

• syntax-aware automatic indenting
• syntax-aware search (project-wide, both “find definition” and “find all uses”)
• arbitrary programming languages
• proportional fonts

Is that too much to ask? Apparently, yes. I haven’t found a single editor that implements all four. TextMate can’t handle proportional fonts. SubEthaEdit can’t indent intelligently. XCode isn’t extensible. Et cetera.

All this is reminding me why I started working on Overleaf. Too bad I don’t have time for it right now. Maybe I’ll get back to it in the sweet by and by after I ship Trifle.

A Year After Switching

It’s been a year since I switched to the Mac. I was hoping for a better user experience, and I got all that and more. OS X and its included apps are a joy to use (well, we don’t talk about the Finder, right?). The Unix underlayer keeps me happy in ways the old Mac OS never could. Cocoa is a fun and productive framework to program in. And I get to use some top-notch applications:

I thought I was happy with web-based RSS readers, but NetNewsWire changed all that. It’s the perfect example of an application that Just Works. On the strength of that, I bought MarsEdit as well, and I’m using it to write this post.

I’m just beginning to use VoodooPad Lite to keep notes about Trifle. I used to keep a local wiki on my Linux box for stuff like this, but the edit/view modality was too annoying. VoodooPad solves that nicely; I’ll probably buy the full version soon.

And then there’s Quicksilver, probably the single best reason to switch to the Mac. Try it, use it, learn more about it.

I wonder how I should celebrate the one-year mark. Now that my iMac’s warranty is up, there’s nothing to stop me from getting a second display and doing some screen spanning…

Cocoa Bindings and Haskell

I’m wondering if Cocoa Bindings are any use to me as a Haskell developer. The whole point of Bindings is to take data from a preexisting Objective-C object and display it in a view, with appropriate syncing in both directions. But if I’m using Haskell data structures to begin with, I’d have to add an extra layer to sync the data with an Objective-C object for Bindings to connect to.

Wouldn’t I be better off eliminating that extra layer, and just implementing my own NSTableDataSource (or whatever) that knows how to interact with Haskell data? Or is there an advantage in having an NSArray in the middle for Bindings and Haskell to interact through? I suppose there are hybrid approaches: I could implement an object that supports the NSArray interface for Bindings’ sake, but actually is all Haskell underneath.

Independent Mac Development

I want to learn about life as an independent Mac developer from those who live it. CocoaRadio is a good resource for that: Blake Burris has made it his mission to track down small-shop Mac developers and pick their brains.

Listening to Brent Simmons on CocoaRadio led me to macsb, a Yahoo group devoted to Mac small business. It leans toward the practical details of running a small software business and making decisions about licensing, activation, etc.

(When I searched for “macsb” just now, Google asked “Did you mean MacsBug?” No. No, I don’t mean MacsBug, and I will never mean MacsBug ever again. [shudder] But then, some things never really change: I spent a chunk of the morning in gdb trying to figure out why PyObjC was crashing on me.)

Core Data

Since I’m writing a database-ish desktop app, I gave Core Data a spin. It offers persistence and undo almost for free, along with extensive and configurable UI bindings.

If Trifle had a data model of any complexity, Core Data would be a good fit. As it is, though, items and tags are so trivial that it’s just as easy to implement them myself. The manual way opens the door for features that Core Data can’t handle, like autosave. And I still get to use a lot of Cocoa power, such as Cocoa Bindings.

The Intel Mac and VirtualPC

I told myself I wouldn’t add to the din of commentary on Apple’s switch to Intel chips, but I can’t hold it in. Here goes:

Steve Ballmer asked “What changed?”, and the answer at first blush is “Not much.” Apple will still make and sell their own machines, supporting the same peripherals, and you’ll only be able to run Mac OS X on a Mac. (Sure, some enterprising hacker will rig up OS X to run on a Dell, but all that will generate is a Slashdot story.)

But the move will encourage fence-sitters considering the Mac to make the switch. First of all, Phil Schiller said they won’t prevent people from running Windows on a Mac. So if you aren’t sure you’ll like OS X, you can buy a Mac, secure in the knowledge that even if you retreat to Windows, you’ll have some decent (if high-priced) hardware to run it on.

Or, if all you have is that one Windows app you still need, you could run VirtualPC (or dual-boot). This is the underreported Big News here: on an Intel Mac, VirtualPC won’t have to emulate an Intel processor anymore. That should make it fast enough for many more situations, and make it easy for the but-I-just-need-this-one-Windows-app crowd to switch.

Implementing Trifle

If Trifle’s going to be a taggable, searchable, versioned, and tailorable data store, how should I implement it? I don’t want to create yet another walled city of data, so Trifle should interoperate like mad with everything around it: applications, Quicksilver, Dashboard, Spotlight, the command line, you name it. So, it needs to tie in to platform-specific frameworks at a basic level — which means that Trifle will be Mac-only. (Question answered.)

Thus, I get the full smorgasbord of OS X features to choose from, without being chained to the lowest common denominator. I can build a Cocoa UI, rather than being limited to DHTML. (This doesn’t preclude an add-on Web interface, but it would require the server to be a Mac.) I can use Spotlight APIs to do full-text search. Who knows, I might even do something crazy with union filesystems.

It feels strange to pick a particular OS to develop for. Under Windows, and even Linux, I never felt enough at home to put down roots. On OS X, I do; I haven’t enjoyed a platform this much since the Commodore 64.

Learning to Love Multiple Windows, Again

As an X11 user in college, I took meticulous care in laying out a bevy of windows on the screen. If my current window manager wouldn’t do what I wanted, I’d just switch to a different one. But when I wound up in a Windows environment after graduating, it was easier to just maximize everything and use one app at a time. (Windows was far less tweakable, and I had lost patience for tweaking in any case.) The advent of tabbed windows only reinforced that tendency.

Now that I’m on the Mac, though, I find myself not only using multiple windows, but enjoying them. It’s the best of both worlds: I can use multiple windows simultaneously, but I don’t have to spend time tweaking window layout. Part of that is just because I have way more screen real estate, but it’s the array of window-management methods that really make it shine: direct manipulation, Exposé, Quicksilver, window hiding, and even the Dock.

This is starting to affect my workstyle at a deeper level. I’m running more applications at once, because it’s so easy to get windows out of the way yet still have them readily at hand. I’m using more simple, single-purpose applications (like Cocoalicious), instead of all-in-one behemoths. I didn’t expect that, but I sure am enjoying it.