Domain of the Bored

From man strftime:

BUGS

There is no conversion specification for the phase of the moon.

Feel free to share your favorite manpage jokes in the comments. (I'll do one for you: the obligatory tunefs joke.)

ICeCoffEE is an APE extension by Nicholas Riley that lets you ⌘-click on a URL in any NSTextView to open that URL in your favorite browser.

But it has another feature that's far more useful than that.

ICeCoffEE is named after ICeTEe, an extension for Mac OS that also provided the ⌘-click feature. ICeTEe added it to TextEdit (that's the “TE” part; TextEdit was the text-editing control in Mac OS, and it's totally separate from TextEdit.app). But ICeCoffEE has one other feature, which I find far more useful. It's a two-part feature:

1. It adds a Services menu to your contextual menu.
2. And you can edit that menu.

What that means is that rather than having to mouse all the way up to the Application menu, then rifle through an enormous list of services*, you can instead simply right-click on the view that already has your focus, and find the service you want among the set of services that you actually use.

(Before you mention ServiceScrubber: That works by editing applications' Info.plists. Not a good way to go about it. I'd rather have services specifically excluded from the Services menu without having to edit any part of the applications. ICeCoffEE provides this.)

This is pretty big. The major reason why people don't use services—even in the face of ThisService, which is the greatest developer tool since Interface Builder—is having to cross half the screen and then wade through several dozen menu items. ICeCoffEE solves both of those problems, so now you have no excuse not to use the full power of services in your work.

It also lets you put the Services menu in the menu bar, but while that beats having it hidden in the Application menu, I don't think that that's as cool as having it in the contextual menu. Worse, it doesn't let you edit the menu-bar Services menu. The one in the contextual menu is a hundred times more useful.

ICeCoffEE is free and a UB, and works in any Cocoa app. You'll need Mac OS X 10.1 or later, though current versions require 10.3.9 or later.

* My Services menu has 46 menu items in it, and that's counting submenus as 1 each. ↶

Today, I scanned in one of my old drawings: a study of five-pointed stars that I made when I was trying to figure out how to draw a proper star (this was at the time of me working on Keynote Bingo MWSF2007 Edition, and a derivative of the same star is used in TuneTagger).

The odd thing is, after I corrected the image using Preview's Black Point and Aperture controls (no relation to the photo-management program), the image weighed about two-fifths as much:

du -b Five-pointed\ star\ study* %~/Pictures(0) 1403443 Five-pointed star study-adjusted levels.png 3346498 Five-pointed star study.png

(These sizes are after pngout, but even if I re-correct the original image and save it elsewhere, it comes out 1790244 bytes long.)

Go figure.

This bug is iTunes should use real combo boxes in its Info dialogs. It was filed on 2007-04-06 at 23:48 PDT.

This bug is Apple applications use a modal window for print progress. It was filed on 2007-03-09 at 14:06 PST.

1. Get out the HP drivers CD.
2. Put it in one of these.
3. Push the button.

Silly me, trying to use a device with the Mac drivers that come with the device. Turns out it works just fine with the built-in Mac OS X drivers, either via PTP (whatever that is), or as a mass-storage device. In fact, Image Capture works the same either way.

With the HP drivers, a program called “HPCamera_PTP” would crash whenever I plugged in the camera, whether I did this in Image Capture or iPhoto. I found that switching the camera to mass-storage mode (“Disk Drive” in the USB Configuration menu) worked around that problem nicely, and Image Capture (and iPhoto) even work transparently in this mode.

Later, I was tinkering with Image Capture in some way (I forget why) and noticed that it has its own PTP driver. This gave me an idea, and having long ago uninstalled the HP uselessware, I switched the camera back to PTP mode (“Digital Camera” in the USB Configuration menu) and plugged it back in. Huzzah! It worked exactly as it did in mass-storage mode.

Kudos to Apple for making it do the Right Thing either way. Antikudos to HP for making non-functional drivers.

I also got a new scanner yesterday, a CanoScan LiDE 600F. Unfortunately, it doesn't work without drivers. Fortunately, its drivers work. (Both devices let me use Image Capture without touching any of the apps that come with them, which I consider mandatory given the nearly-consistent asstasticity of the UIs of such apps in general.)

I missed a couple of weeks of ABF, so I'm going to run the missed Fridays' bugs today in addition to today's.

This bug is Feed button does not use the standard feed icon. It was filed on 2007-02-16 at 12:27 PST.

First, the article.

The DRM-opponents' response

Holy shit.

The response from the RIAA and its member organizations

Oh shit.

The response from Microsoft, Creative, et al

Shit.

A few weeks ago, I installed Adobe Reader to view a particular PDF, and noticed something interesting in its Preferences:

“Wow”, I thought, “I wonder how it knows that.” So I went looking through the Quartz Display Services documentation, and found it.

The function is CGDisplayScreenSize. It returns a struct CGSize containing the number of millimeters in each dimension of the physical size of the screen. Convert to inches and divide the number of pixels by it, and you've got DPI.

Not all displays support EDID (which is what the docs for CGDisplayScreenSize say it uses); if yours doesn't, CGDisplayScreenSize will return CGSizeZero. Watch for this; failure to account for this possibility will lead to division-by-zero errors.

Here's an app to demonstrate this technique:

ShowAllResolutions will show one of these windows on each display on your computer, and it should update if your display configuration changes (e.g. you change resolution or plug/unplug a display). If CGDisplayScreenSize comes back with CGZeroSize, ShowAllResolutions will state its resolution as 0 dpi both ways.

The practical usage of this is for things like Adobe Reader and Preview (note: Preview doesn't do this), and their photographic equivalents. If you're writing an image editor of any kind, you should consider using the screen resolution to correct the magnification factor so that a 8.5×11″ image takes up exactly 8.5″ across (and 11″ down, if possible).

“Ah,”, you say, “but what about Resolution Independence?”.

The theory of Resolution Independence is that in some future version of Mac OS X (possibly Leopard), the OS will automatically set the UI scale factor so that the interface objects will be some fixed number of (meters|inches) in size, rather than some absolute number of pixels. So in my case, it would set the UI scale factor to roughly 98/72, or about 1+⅓.

This is a great idea, but it screws up the Adobe Reader theory of automatic magnification. With its setting that asks you what resolution your display is, it inherently assumes that your virtual display is 72 dpi—that is, that your UI is not scaled. Multiplying by 98/72 is not appropriate when the entire UI has already been multiplied by this same factor; you would essentially be doing the multiplication twice (the OS does it once, and then you do it again).

The solution to that is in the bottom half of that window. While I was working on ShowAllResolutions, I noticed that NSScreen also has a means to ascertain the screen's resolution: [[[myScreen deviceDescription] objectForKey:NSDeviceResolution] sizeValue]. It's not the same as the Quartz Display Services function, as you can see; it seemingly returns { 72, 72 } constantly.

Except it doesn't.

In fact, the size that it returns is premultiplied by the UI scale factor; if you set your scale factor to 2 in Quartz Debug and launch ShowAllResolutions, you'll see that NSScreen now returns { 144, 144 }.

The Resolution-Independent version of Mac OS X will probably use CGDisplayScreenSize to set the scale factor automatically, so that on that version of Mac OS X, NSScreen will probably return { 98.52, 98.52 }, { 96.33, 96.33 }, or { 98.52, 96.33 } for me. At that point, dividing the resolution you derived from CGDisplayScreenSize by the resolution you got from NSScreen will be a no-op, and the PDF view will not be doubly-magnified after all. It will be magnified by 133+⅓% by the UI scale factor, and then magnified again by 100% (CGDisplayScreenSize divided by NSDeviceResolution) by the app.

Obviously, that's assuming that the app actually uses NSScreen to get the virtual resolution, or corrects for HIGetScaleFactor() itself. Adobe Reader doesn't do that, unfortunately, so it suffers the double-multiplication problem.

So, the summary:

• To scale your drawing so that its size matches up to real-world measurements, scale by NSDeviceResolution divided by { 72.0f, 72.0f }. For example, in my case, you would scale by { 98.52, 96.33 } / { 72.0, 72.0 } (that is, the x-axis by 98.52/72 and the y-axis by 96.33/72). The correct screen to ask for its resolution is generally [[self window] screen] (where self is a kind of NSView).
• You do not need to worry about HIGetScaleFactor most of the time. It is only useful for things like -[NSStatusBar thickness], which return a number of pixels rather than points (which is inconvenient in, say, your status item's content view).

1. Print out all the letters and some punctuation onto sticker paper. For a US keyboard, you'll need the alphabet except a and m, and all of “-=[];'/,.” I've forgotten the font I used (it was years ago that I did this), but I can offer you this: On my keyboard (a Macally iKey), the letters are 4 mm tall.
2. Cut out the characters and affix each one to the matching key in the Dvorak position. For example, the ‘p’ goes on the QWERTY ‘r’ key (top row, fourth in from tab). Using labels rather than rearranging your keys allows you to easily switch back to QWERTY if you should need to for something.
3. Hunt-and-peck with this arrangement. Do as much typing as you can arrange for yourself. Pay attention to the letter arrangement, which is not accidental—the vowels are all together on the left and many common digraphs (e.g. tr, nt, ?s, th) are on the right.
4. When not at your computer, air-type in the Dvorak positions. This gets you used to the finger movements. Muscle memory is your friend. Anytime you daydream, or speak, or hear speech, narrate it in text on a keyboard of air. You don't need your arms in position for this; at your sides/in your pockets will work just fine. It's your hands that you're training.
5. At the end of about two weeks, the stickers will fall off of the keys, and you will not complain because you have ceased to need them.

It wasn't much longer before I had matched my old QWERTY speed, and I've since surpassed it—I type around 100 WPM. (Curious as to your own WPM? Try this free typing test.) I'm rusty with QWERTY now, but I can still type it if I need to.

5G iPod users, listen up: Apple is offering a demo of its Vortex game.

Just to save you the time of trying this yourself, the answer is yes, you can use arbitrary queries with SpotlightFS.

mkdir 'kMDItemTitle = "A Day In The Life"'             %/Volumes/SpotlightFS(0)
___
ls 'kMDItemTitle = "A Day In The Life"'                %/Volumes/SpotlightFS(0)
:Users:prh:Music:iTunes:iTunes Music:The Beatles:Love:23 A Day In The Life.m4a@
:Users:prh:Music:iTunes:iTunes Music:The Beatles:Sgt. Pepper's Lonely Hearts Club Band:13 A Day In The Life.m4a@
:Users:prh:Music:iTunes:iTunes Music:The Beatles:The Beatles 1967–1970:1-06 A Day In The Life.m4a@
Icon?*
___
mkdir 'kMDItemTitle = "A Day In The Life" && kMDItemAlbum = "Sgt.*"'
___
ls 'kMDItemTitle = "A Day In The Life" && kMDItemAlbum = "Sgt.*"'   
:Users:prh:Music:iTunes:iTunes Music:The Beatles:Sgt. Pepper's Lonely Hearts Club Band:13 A Day In The Life.m4a@
Icon?*

I also would suggest defining a shell function that does the mkdir-ls-rmdir dance in one step.

In MacBreak episode 56, Merlin Mann talks to (among other people) Dan Moren of MacUser, who I think inadvertently states the reason why Apple has not released an SDK for the iPhone. From 1m25s:

Merlin Mann: And what I wanna know from you is, if you had a software development kit today, and you could walk home and, I don't know, go learn Xcode, and make the application of your choice, what would you put on an iPhone?

Dan Moren: I think that the most compelling thing is to take on Cisco with their iPhone, with the VoIP capabilities? I mean, I'd like to see some Skype on the iPhone. If you got the WiFi in there, you got some, you know, 3G or something, but for those of us who don't wanna switch to Cingular, you know, and you still want some voice capabilities, why not be able to develop a Skype, put in some voice communication application in there, … it'd be great to have some kind of AIM functionality too.

I think that's it. The iPhone is closed because if it wasn't, you'd be able to use the iPhone without continually paying for Cingular phone calls or SMS (by using Skype and $IM_SERVICE instead).

That means that if they do make an SDK, it won't be available until at least two years from June.

BBEdit Lite 6.1.2 vs TextWrangler 2.2:

Maybe it will come with Xcode 3?

UPDATE 20:55: Never mind.

• John Siracusa's
• Mine
• freenode/#macnytt
• Undernet/#macintosh (#macnytt's GUI + my strings + #macintosh's strings)

This is a response to Daniel Jalkut's iTunes Script: Recent Podcasts.

It is possible to do what he does with scripts with smart playlists. The result requires no user action to update, since the playlists will update automatically. You can even use them to sync recent podcasts to your iPod.

We start with a playlist for all podcasts:

This smart playlist provides the same function as the script with its kIgnoreAlreadyPlayedPodcasts property set to its default value of false. If you like kIgnoreAlreadyPlayedPodcasts set to true:

This playlist derives from the first one, and you can replace the Playlist rule with the three rules of the other playlist if you don't want a played-or-not playlist hanging around.

UPDATE 2007-01-08: Daniel Jalkut pointed out that there's a Podcast criterion that I could have used. I completely missed it. This makes the solution much simpler:

PBS is looking at three science-show pilots, and can't decide which one to order as a full series. So they've made all three pilots available, for free, and ask your opinions on them (perhaps by iTunes commenting — I haven't watched the videos; there may be instructions within them or something). Each show is a full hour. They are:

• “Wired Science”, from KCET (channel 28 in Los Angeles — have I mentioned that I'm in the LA TV market?) and Wired Magazine.
• “Science Investigators”, from WGBH. Possibly related to History Detectives?
• “22nd Century”, from Towers Productions and Twin Cities Public Television.

The Areas of My Expertise by John Hodgman (aka a PC, aka The Daily Show's resident expert), read by the author. All six hours, 58 minutes of it. Free.

So I'm looking at making some screencasts in iShowU. I noticed that, thanks to QuickTime, it supports rather a lot of codecs:

Dizzying, isn't it?

So I asked the Goog about some of the codecs, and also more generically about screencast codecs. H.264 is a popular choice, but I found no comparison to other codecs nor any discussion of what any of the codecs is particularly good at.

I also had a small amount of previous experience with the difference between codecs. I've watched two of rentzsch's screencasts: “Introduction to Core Data” and “Embedded Cocoa Frameworks”. The former is 1024×768 using H.264; the latter is 800×600 using Sorenson 3. “Introduction to Core Data” looked flawless; “Embedded Cocoa Frameworks”, OTOH, had noticeable artifacts. I wondered at first what the difference was, and after I found out, whether there wasn't a better codec with which to implement screencasts.

Part of the problem is that there really isn't a codec that's been well-optimized for screencasting. Video codecs have historically been optimized for, well, video — that is, video shot with a camera. Screen images usually don't change much except to follow mouse movements; a compressor specifically optimized for recording the screen should make a big difference in screencast file sizes. Are you listening, Apple? (Or Ambrosia?)

Anyway. In order to find the perfect (so far) screencast codec, I recorded a brief screencast using iShowU in demo mode using the None (no-compression) codec, and used QTAmateur by Michael Ash to export it to all the other codecs.

The results? Well, you'll just have to read the screencast codec showdown for yourself. ☺