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.

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).

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]

I’ve been using an Apple Mighty Mouse (bluetooth) for years now, so for years I’ve been dealing with a scrollball that occasionally gets stuck.  As someone who used to use mice that relied on a physical ball for tracking, this is nothing new.  The only real difference is that we can’t remove the scrollball to directly ungunk the mechanics.  My personal preferred way to ungunk/unstick/clean the scrollball (and mind you, for all I know, this might destroy your mouse) is to turn the mouse off, take a q-tip, soak up some denatured ethyl alcohol, and rub it around the scrollball, rolling the ball in every possible direction to try to get as much of the alcohol down and around the ball as possible, hoping to loosen up any gunk in the works there and bring it up top where it can be wiped away.  Typically, this unsticks the ball and brings some visible gunk and stuff to the topside.  It also helps to press down on the ball while rolling it around to ensure that it is moving the mechanical bits with which it has contact.  Let the mouse fully dry before turning it back on.

What’s noteworthy about this failure, though, is that it’s the first time I’ve had a drive fail and lost absolutely nothing.  The drive was half of a software RAID1 setup.  OS X’s Disk Utility showed the drive with SMART status “failing” and showed the RAID as “degraded” but was still able to make a complete copy of the RAID to another drive.  Even supposing the RAID hadn’t survived, all of my data except possibly the most recent hour is backed up to yet another drive via Time Machine.

I’m not going to claim the system is bulletproof (I’m sure it isn’t), but it is nice to see a redundancy/backup plan actually work when tested by the real world.  I’m just waiting on a cross-shipped replacement from WD to rebuild the RAID.

Remember: it’s not if your harddrive fails, it’s when your harddrive fails.  Drive failure is inevitable.

Edit: The replacement from WD was shipped next-day air, so I’ll have the new drive tomorrow.  First business day to process the RMA, second business day to ship the replacement, and the replacement arrives on the third business day.  Pretty fast.

Dropped dramatically, but not entirely.  The underlying issue seems to be mislabeled antenna wires.  I’d made an earlier pass at trying this fix, but failed because I couldn’t find any of the other wires I was supposed to use in place of the one labeled “BT” that was attached to my bluetooth module.  Just now, however, with some more disassembly, I was able to find the other wires, swap the “BT” wire for the only other wire long enough to reach, and now my keyboard and mouse work from across the room.

Details:  Read this and this.  Open the case, remove all four SATA brackets/drives.  If you can see all four antenna wires, great, go for it!  (That is, swap the “BT” wire for the only other wire long enough to reach.  If you’ve got the Airport module, see those two links to figure out how to deal with those wires.)  If not, as it was for me, remove the heatsink cover (bottom-middle of case) and the front fan assembly (bottom-front of case), then poke around in the bundles of wire behind SATA bay 1, top of the motherboard/logic board, toward the front of the case.  That’s where I found the wires I needed.

To remove the heatsink cover, grip it at the edge closest to the motherboard and lift and pull toward you–it’s held in place by a few magnets, no latches or anything.

To remove the front fan assembly, unscrew the screw that goes through the motherboard at the top-right of the fan assembly and possibly look for a screw at the bottom-right of the assembly, just under where the heatsink cover was.  Once those two screws are removed, pull the assembly straight out of the case (perpendicular to the motherboard)–it slides in a track along the bottom of the case and pulls away from a plug on the motherboard (no cables to worry about).

• asLJCore is the primary component of the LiveJournal client asLJ, managing all communication with the server.
• YDDecode is a Cocoa class wrapped around some public-domain C code for decoding data encoded with YEnc.
• NCIDStatusBarMenu is a utility to help pull NCID-based callerID notifications and display them as Growl notifications (among other things).  I’d been meaning to update it for nearly 2 years with no success and the future isn’t looking much better, so I’m releasing the source instead.

(My musings on licensing below the cut.)Permissive BSD/MIT licenses because in writing asLJ among other things, I’ve had to work to find libraries, frameworks, components, classes, etc., that weren’t GPL-licensed so that I could continue to choose how I wanted to release my software.  I am also heavily influenced by the simplicity of the BSD and MIT licenses compared to the lengthy GPL (and while the LGPL ought to be workable for many libraries, I couldn’t quite wrap my head around the language of it–the LGPL is several paragraphs of modification to the GPL).

(The song lyrics and commentary for OpenBSD4.3 have a lot to do with how I feel about GPL versus BSD/MIT.)