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.

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]

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

I stumbled into Fluid when I was looking for a way to keep my RememberTheMilk task list open on the side somewhere rather than always having a Firefox tab devoted to it (and trying to remember not to just close the Firefox window).  With Fluid, not only do I have an app dedicated to my RTM task list (and, since installing Gears into Safari^* makes it available to Fluid SSBs, it should have some ability to function offline, too), but I was able to create a separate menu-extra type app with the gadget interface to RTM so I can also access my task list quickly in the menu bar.

Having done that, it was a short skip over to having a proper Google Calendar app.  Nothing special there yet, save for the same hope that Gears will make it work offline.

More usefully, I found this post about using Fluid and Hahlo along with some scripting to create a pretty good Twitter client that even uses Growl notifications.  That post has all the links you need, including a direct link for the script and a link to a usable icon on Flickr.

Better still, it occurred to me tonight to apply Fluid to Lala.  With Fluid’s option to hide the window when the user closes it, rather than actually closing it, I can “close” the window that has Lala and it keeps playing.  If I go back to my Lala SSB app, the window pops right back up.

Mind you, while all this web-app-turned-mac-app stuff is nice, the biggest benefit is probably the fact that if my web-browsing browser crashes, it doesn’t take my web apps with it and no one of my web apps can crash the others.  Unfortunately, Webkit seems to share one big cookie jar among all its instances, so separate Fluid-created instances won’t allow you to simultaneously log into the same site using different credentials if you couldn’t already do so (the login cookies will clobber each other and/or any such Safari cookies… though Firefox’s cookie jar is separate from Webkit’s…).

^*note that, interestingly, the Gears site displays an essentially blank page with no help or guidance whatsoever if you have javascript turned off in Safari (I mast have been testing something or other without javascript and forgotten to turn it back on).

The not-so-new trick has been to use AppleScript on the command line to not-so-harshly close some applications (run osascript, then tell application "program name" to quit, followed by ctrl-D (EOF).

The new trick is to sudo kill SecurityAgent, sudo run SecurityAgent, put the machine to sleep, then wake it back up (necessary to get SecurityAgent to put up a new password window).

aslj_client

aslj_users

(As it is very LJ-centric, most of the information about it will be over at LJ, in the two places linked above, but there is a page for it here, as well.)