New releases: TapeDeck and Pyrothèque

TapeDeck, my exciting joint project with Chris Liscio of SuperMegaUltraGroovy, has made it all the way up to version 1.0.3 without so much as a mention over here on toastup!. The latest release fixes a few more quirks that we’ve discovered in the weeks since TapeDeck’s big introduction last month.

More recently, Pyrothèque got a long-overdue update. Version 1.1.1 incorporates almost a year’s worth of minor bug fixes, including an adjustment to the rocket launcher to better position explosions on monitors of odd sizes and proportions. (That means the fireworks ought to show up properly now, Mister Thirty Inch Cinema Display.)

Web site fixes

One of Google’s robot army helpfully informed me last month that spammers had exploited a hole in the version of WordPress used here at toastup!—resulting in lots of invisible nasty spam keywords that got the blog evicted from Google’s index. The hole’s now been patched, so (hopefully) we’ll re-appear in your search results in the near future. I’ve also gone through and fixed up earlier blog posts that were mangled by the update, so you should be able to see images again in the popular LCD Scrub article, among others.

And, finally—

Expect updates to be light for several months, as we’re expecting a rather large new “version” here at toastycode HQ in the next few weeks. Please don’t hesitate to get in touch (using the email link below, or in your toastycode software product) if you have questions or find any bugs—but also please understand if my replies are somewhat in arrears.

LCD Scrub version 1.0.1 (download)

Foam version 1.3.1 (download)

If you run into any trouble with these new versions, please get in touch using the email link at the bottom of this page. Release notes:

Changes in LCD Scrub 1.0.1

• Fixes registration problems for some users.
• Now shows license agreement when entering registration code.
• Other small improvements.

Changes in Foam 1.3.1

• Uses a different (better) pseudorandom number generator to improve randomness of bubble placement. (The previous method was OK, but could cause repeated sequences when invoking Foam in rapid succession.)
• Fixes a pretty silly infinite loop that the preferences would enter if you selected no color combinations.

Every piece of software available here at toastycode exists first and foremost because it was something I wanted to use and, finding it not to exist, had to go about creating it. Pyrothèque is a perfect example: I had fond memories of Pyro!™—perhaps the granddaddy of all screen savers—and wanted to bring its iconic B&W fireworks back for a revival.

OK, now that that’s out of the way, let’s talk about LCDs.

At my office I have my Mac workstation hooked up to a 19″ flat-panel display from Dell (the 2001FP). I drive it over DVI at native resolution (1600×1200), which is totally sufficient for my multitasking needs.

April 25, 2007

One sunny Wednesday morning, I arrived at my office to find this:

The standard “Computer Name” screen saver was running¹, but something was very, very wrong. Bright green lines streaked down the black areas of the screen, while green echoes smeared rightward off displayed images. The entire screen was dusted with stray green pixels, sparkling and popping like TV snow.

Not good.

It turned out that my officemate had used my iSight/iChat setup the previous evening. He must have swiveled the monitor around when he was finished; it was torqued so far out of position that the DVI cable came loose (with a few bent pins for good measure). Somehow the cross-talked DVI signal resulted in the green noise, which danced on my screen all night long.

The video, it burns

Here’s where it gets interesting. When I replaced the DVI cable, the screen almost went back to normal: my Mac’s screen was now covered in dark shadows where the searing green had been. It was like having CRT burn-in.

I continued using the monitor for the rest of the day, but the lines were distracting, irritating, and deeply concerning: I didn’t want to have to tell my adviser that I’d busted my shiny LCD panel². I turned it off overnight, hoping to release whatever bad mojo had found its way in there, but when I powered it back on the next morning, the lines were still there.

I turned the display off when I went home, and over the course of normal use over the next few days, the ghosts faded a little, but were still pretty annoying. I came in a couple of days later with a better camera³ and took some close-up images of the burned-in areas:

Over the weekend I did some research. I had always assumed that flat panels couldn’t get burn-in⁴; it turns out I (along with countless LCD salespeople) was mistaken. LCDs can instead get image persistence (aka image “retention” or “ghosting” or “traces”), and manufacturers disagree as to exactly why it occurs; perhaps stray charge, maybe combined with heat and “ionic impurities”, or some other abstruse electrochemical condition.

What is universally acknowledged is that one image, displayed for a long time, will tend to leave an after-image on an LCD screen or TV. High-contrast static images (like my green lines) are the worst. There also seems to be some consensus that Dell displays are particularly prone to this sort of thing. Lucky me.

Prevention and repair

The common recommendation, from manufacturers and message boards, is: don’t leave a static image on your screen. (So keep using those screen savers, folks.) Which is all fine and well, but what to do with a screen that’s already burned?

Finally, some good news: it turns out that image persistence is usually reversible (something that was never possible with CRTs). I quickly found Apple’s recommendation for eliminating image persistence: Create an all-white image in Photoshop and set up the photo-album screen saver to use just that one image. (Other manufacturers and forum posts also recommend displaying a solid white image.)

I tried the solid white image technique for a day, but for whatever reason, the lines were still there. After reading the NEC white paper talking about fixed high-contrast images causing persistence, though, I wondered: Could I use moving high-contrast images to “scrub away” and smooth out the excess electrical charge (or whatever it is that causes the problem)?

Scrubbing solution

I set about building a screen saver module that would let me try different high-contrast patterns to see how they fared. Furthermore, since patterns with thin bright lines caused the problem, I set about using similar line patterns to ameliorate it.

It worked.

After a day of using the high-contrast patterns, the lines were almost invisible; the next day they were gone.

So, to recap: Dan’s LCD is hosed; Dan does a bunch of Internet reading, tries a bunch of stuff, creates a solution that works; Dan doesn’t have to get a new monitor. Q.E.D., the end.

An epilogue—and also a preface

I thought I was done with LCD scrubbing forever; with my display fixed, my screen saver properly configured, and my DVI cable securely screwed to the back of my display (!), I was free of the whole issue.

And then I started hearing, from friends and family who had heard the sob story of how my monitor was ruined and how I fixed it, that I should make this tool available to everyone. “Our office’s IT guy just threw a few LCDs away,” said my brother-in-law. “They had burned-in logos and patterns, and we couldn’t use them like that. I told him about your scrub thing, and he said, where can I get that?”

“Don’t you sell software?” he added, somewhat irritably, to my blank stare.

So, here we are: A few months later (well, more than a few; it’s been a busy time for my other career), I present LCD Scrub 1.0.

It’s a descendant of the same screen saver I wrote for myself last spring; to use it, set your energy saver settings to never turn off the display, and your display settings to your LCD panel’s native resolution. Then select LCD Scrub as your screen saver, pick a pattern, and let it run overnight. If you don’t see any improvement, try another pattern.

You can download a trial version from the LCD Scrub page; it will run for 20 minutes so you can see how it works and decide if you want to purchase it. The full version (without time limits) costs just $18.

If LCD Scrub doesn’t work on your display, shoot me an email (with photos of the problem, please) and we’ll try to figure out how to improve the software. I can’t guarantee that it will work in every case of image persistence (having only a limited set of screens to test it on) but, as it uses Apple’s recommended techniques along with my additional high-contrast patterns, I expect it to be effective on all but the most severe cases of image persistence.

Download LCD Scrub and give it a shot.

The new version includes the usual heap of bug fixes and unremarkable tweaks, and adds the following nifty new features:

• For registered users: Cuckoo can now optionally toll the hour (that is, play the sound five times at 5:00) at the top of the hour. This is one of the most often requested Cuckoo features, the other being different sounds at different times.¹
• Includes a new clock-tower sound called “Campanile”—quite effective when tolling the hour as described above. BONGGGGG. (Because it’s built in to Cuckoo, this sound is available in Cuckoo’s free mode.)
• Finally, the de rigeur background checking for software updates. If the appropriate box is checked, Cuckoo will check the toastycode website every few days for new releases. If an update is available, the Cuckoo preference pane will open automatically and you’ll be given the opportunity to download the new version—or ignore or defer it. Cuckoo won’t make any changes to your system (you’ll have to double-click the new version to install it) and no personally-identifying information is be sent in the update query. ²

Please download the new version, and then consider stopping by iUseThis to vote for Cuckoo. Happy holidays!

I hope December finds you well and with family or friends. I was hoping to have Cuckoo 1.2 ready for you by now, but time seems to have gotten away from me.

While you’re waiting, here’s a little treat: an audio clip of sleigh bells you can use with Cuckoo for a little bit of holiday cheer on the hour (or, you know, whenever). Download it below, double-click the .zip to expand, and then place the mp3 in your Library/Sounds folder.

Happy holidays, and I’ll see you in 2008.

tell application "System Preferences"
    activate
    reveal pane id "com.toastycode.Cuckoo"
end tell

That is, you can use reveal pane localizedName or reveal pane id bundleId to tell SysPrefs to switch to a given prefPane. This is an improvement on reveal in earlier versions of the OS, which only supported the reveal anchor someTabName in pane name phrasing, which doesn’t fly if your preference pane doesn’t have tabs. (As noted here, you can use the pseudo-anchor main on Apple’s tabless prefPanes, but I couldn’t find any kind of documentation on how to add “main” to my own prefPane.)

If you try the 10.5-style reveal pane syntax on Tiger and earlier, you’ll be rewarded with a less-than-elucidating NSReceiversCantHandleCommandScriptError. (Try saying that three times fast. Or, uh, once.)

The following AppleScript will work on all releases of Mac OS X, however:

tell application "System Preferences"
    activate
    -- works in 10.4 and 10.5
    set current pane to pane id "com.toastycode.Cuckoo"
end tell

Just thought I’d share in case there’s some other poor soul out there trying to launch a specific preference panel from AppleScript or Cocoa.

There’s another minor fix for Mac OS X 10.5 users, and it has to do with one of the new security features in the OS. Read on for the details.

In Leopard, when you download software from the Internet using Safari, an invisible “quarantine” label is applied to the file. Then, when you (or any other entity, including automated tasks and login items) launch the application for the first time, the Finder notices the quarantine and first asks the user if the application is OK to launch.

While this feature has proved somewhat annoying for advanced Mac users (who have already invented ways to disable it), everyday users ought to appreciate the fact that the new Finder is looking out for them.

For preference panes, the process is a little bit different. When you double-click on a .prefPane file (like Cuckoo.prefPane) to install it, Mac OS X has always presented a dialog to confirm the operation. In Leopard this process is unchanged (and, in fact, doesn’t mention the quarantine at all, which may very well be a bug). In the case of Cuckoo, the prefPane is installed and the CuckooChimeAgent—the background application that takes care of chiming at exactly the right moment—is automatically launched.

The trouble comes when you reboot and see this dialog:

The prefPane installation process appears not to lift the quarantine on downloaded items (another small Leopard bug), and (as stated earlier) Login Items are subject to quarantine. So the user is presented with this perplexing dialog the first time she reboots 10.5 after installing (or updating) Cuckoo.

The latest version includes code to explicitly remove the quarantine label from CuckooChimeAgent once you’ve already approved the installation of Cuckoo itself. Future bug fixes to Leopard may make this unnecessary, but for the time being, it should save some extra clicking (and possibly some extra confusion, especially if you don’t reboot very often, in which case this dialog—appearing a long time after you’ve installed Cuckoo—will be very puzzling indeed).

My only gripe: Why does the new Finder take Cuckoo’s pretty birdhouse icon and cram it into a tiny little badge stamped on a generic “PREF” document? You can barely see it, even at 128×128 pixels (see below). For shame.

We can only hope he was referring to Pyrothèque.

I was wondering if this script could be modified to remove all login items from all users and not just the currently logged in one? We have about 30 computers with at least 6 users each that we need to remove all the login items from. Think it would be possible?

It turns out that because loginitem uses AppleScript to ask System Events.app to do the work, it’s fundamentally limited to operating on the current user’s login items. We’ll need some other way of manipulating those settings. Fortunately, this particular problem (deleting all login items) has a convenient solution.

Referring back to Apple’s documentation, we see that a user’s login items are stored in ~/Library/Preferences/loginitem.plist. For a single user, it’s sufficient to delete the AutoLaunchedApplicationDictionary key and log out and in again, but we’re trying to automate this process across a number of users.

Here, finally, is the recipe:

1. Create a “pristine” version of loginitem.plist, with no login items in it. You might do this by opening ~/Library/Preferences/loginitem.plist in Property List Editor and deleting the AutoLaunchedApplicationDictionary key, or by running the command:

   defaults delete loginwindow \
        AutoLaunchedApplicationDictionary

2. Stash that file somewhere:

   cp ~/Library/Preferences/loginitem.plist /tmp/

3. Run:

   for aHome in /Users/*; do
     sudo cp /tmp/loginitem.plist \
       $aHome/Library/Preferences/
   done

[Theoretically it should suffice to simply delete the loginitem.plist file, since the remaining values in that file (BuildVersionStampAsNumber, etc.) seem like the sort of things that the system could re-create for you. I don't know if it does, though, so the safest bet is to preserve them.]

Exercise: Convert your pristine loginitem.plist to text (either with defaults read or plutil); embed in a script; ssh in parallel to all the Macs in your lab, downloading and running the script on each.