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.

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

On the other hand, ssh is a very robust protocol and somehow ssh sessions seem to readily survive disconnect/reconnect cycles. Making use of this, it is possible to get a workable, if slow, connection to a passworded-and-sleeping Mac.  On one connection to the firewall machine, run a loop of the wake-on-LAN command so that the magic packets that make the Mac wake are being sent every second or so.  Use another connection to ssh into the Mac and do whatever you need to do.  It helps to plan out what you need to do so that you can get the commands in fast, but even during the cycle where the Mac goes back to sleep and gets reawakened by the wake-on-LAN loop, you can type commands; they just won’t appear (not even echoed) until ssh recovers the connection.

While this is an annoying way to use a machine and it’s probably not good for the hardware to cycle in and out of sleep repeatedly in such a short time span, it does give a way to get at a passworded and sleeping Mac remotely.

If the price is even remotely reasonable when the final version is available, I think I’ll be sticking with it.