MacWJ requires OS X 10.5 or newer and some sort of tablet-pen input, whether a tablet-form computer or a Wacom graphics tablet or something else of that sort.  Ready-to-run recent build(s) are available on bitbucket, as well as the full source code.

My one complaint with the setup described is that the script for the “Run Script” build phase described there is a maintenance headache that I could do without.  Here’s my solution:  Create two new build targets, both of the “Shell Script” type–these are targets that just run a shell script, so they are created with only a “Run Script” build phase.  I called my two new targets “Create/Update English .strings files” and “Create/Update l10n XIBs” but you can call them whatever you want.

In the “Create/Update English .strings files” target’s “Run Script” phase, the script is:

This uses ibtool to create a strings file for every XIB in the English localization (from foo.xib, foo.xib.strings will be created).

In the “Create/Update l10n XIBs” target’s “Run Script” phase, the script is:

This goes through every .lproj directory except English.lproj and uses ibtool to apply the .xib.strings files in those localizations to the XIB files in English.lproj.

By having these as two separate targets, they aren’t run every time I build and each part can be run on its own, on demand.  By using the power of shell scripting, I avoid having to alter the scripts for every new localization or XIB.

If this is of concern for some reason, for the things that were under BSD license and no longer are, the version-controlled repositories still have older versions that are BSD-licensed.

This takes the CFBundleVersion from the project’s Info.plist, adds a period and the subversion revision number, and injects that into the Info.plist of the built product.

When I made the move to Mercurial, I couldn’t quite do this anymore.  While subversion revision numbers are monotone increasing and consistent everywhere (they are the unique identifiers of a particular version), Mercurial’s “revision numbers” are local to a particular instance of the repository and may not match up from one instance to another.  Mercurial uses a hash as the unique identifier of a particular version, and these hexadecimal hashes are not monotone, making them unsuitable for use in CFBundleVersion.

Though it took some time, I’ve finally come to a system with Mercurial that I think is workable:

This calculates the number of minutes between the most recent tagged ancestor of the tip and the tip itself and adds that to the CFBundleVersion.  Because it’s time-based, it is guaranteed to be monotone increasing, consistent, and unique (well, provided multiple commits don’t happen within a 1-minute span, which is safe for me).

A little over a month ago, I went back and played with Mercurial some more, and it just clicked.  I think it had something to do with reading the Mercurial guide, but I couldn’t really put my finger on it.  That is, until a few days ago, when I read Distributed Version Control is here to stay, baby.  Joel’s explanation of his transition to DVCS really hit on the shift in thinking that took place for me in moving to Mercurial.  Plus, it has one of the best lines I’ve ever read in a blog post:

It still has some quirks:

• behavior is strange when the pop-up is above the combo box (whereas it is usually below) [fixed; when the pop-up is above the combo box, the drag-handle is at the top and the top edge moves while the bottom edge stays fixed at the combo box]
• the formula for resetting the number of visible items after dragging occurs is not quite right [fixed; dragging now snaps to whole-item positions]

$39.90 for unlimited 2-year wildcard certs is a whole heck of a lot cheaper than anything else I’ve seen.  In fact, that’s not much off of what I’d been paying for 2 years of a single-site certificate, having done a lot of comparison-shopping.  And it’s really hard to beat free for single-site certificates.  It’s an easy replacement for self-signed certificates at the same price.

At some point, I came to my senses and moved to IMAP, simultaneously moving back to hosted email (because, really, hosting an email server on a home machine is a mess), but with a provider that only hosted email.  IMAP was, at that moment, the ultimate solution to my issues of email being out of sync between multiple computers.  On the other hand, with IMAP, all of my email lived on the hosting company’s servers, so having an email hosting company that knew what they were doing was important.

The other major issue in the move to IMAP was filtering.  I had well over 100 filter rules in Eudora when I stopped using POP.  With IMAP, I no longer had to have filtering rules on every instance of my mail client, but I had to set up the filter rules in the framework allowed by my email host.  (One provider had a Bayesian filter system that could be set to learn from every message move made via IMAP, which was cool, but slow to learn and not accurate enough.)  As time went on, and through changing email hosting providers, this became very cumbersome (especially compared to using procmail on a receiving account, which is how I selectively filter the email that goes to my Blackberry).

When I finally gave up on the hosting company’s email filters, I had nearly 150 filters and there were dozens more I wanted, but just couldn’t be bothered to set up.  With 150 filters and no simple way to group and arrange them, managing the filters was impossible.  If I wanted to rename a mailbox that was the destination for a filter, I had to hunt down the filter and change it, which meant digging through a massive webpage listing of 150 filters.  But using an email hosting provider was non-negotiable for me.

After much searching for ways to run procmail on a remote IMAP account and finding nothing, I finally settled on trying imapfilter.  At first, dealing with the Lua scripting language used to configure it was tedious, but it was easy to learn and thus wasn’t a problem for long.  Now, a week into using imapfilter, my config.lua file is 372 lines long–it’s doing all the filtering I’d been doing through the email hosting company interface, all the filtering I wanted to do, grabbing some spam that persistently evaded the spam filter system, and automatically taking messages that I put in my Junk folder and sending them back to the spam filter system’s reporting address.  I have imapfilter running on a VPS (which I use for a variety of utility things) via cron job every few minutes.  When I want to add a new filter or change the behavior of an existing filter, I can just fire up (Mac)Vim, open the remote file, and apply the power of Vim for quick and easy editing.

It’s the biggest difference in my email use since the move to IMAP.  If you’re using IMAP and you want more powerful/flexible filtering, you should definitely look into imapfilter.