Idle Time

This bug is hdiutil provides no facility to change bzip2 block-size. It was filed on 2007-05-25 at 13:49 PDT.

(more…)

This bug is User 501 gets the admin bit after migration. It was filed on 2007-05-25 at 13:29 PDT.

(more…)

Ordinarily, I’d post this on del.icio.us, but this isn’t on developer.apple.com and I don’t think del.icio.us allows file: URLs.

Most use of Core Audio goes through Audio Units, but the Audio Unit API has historically been undocumented. Today, I finally found the Audio Unit documentation. Turns out that, rather than being in the /Developer/ADC\ Reference\ Library/Documentation folder (where you would expect documentation to be), it’s hidden in the /Developer/Examples folder. This documentation is so good (damn near production-quality) that I feel like I’ve struck a rich vein of gold ore.

WTF, Apple?

This is a partial list until Friday night, but it’s worth posting now because of all the people I met at the WWDC Bash.

Where possible, I’ve also listed their IRC nickname.

Adium-related people I met at WWDC

• Colin Barrett (cbarrett)
• Brian Ganninger (whom I’d previously met at the Google Summer of Code Mentor Summit) (bgannin)
• Patrick Gibson (patch writer, not developer) (pblair)
• Elliott Harris (eharris)
• David Smith (Catfish_Man)

Other people I met at WWDC

• Karl Adam (PantherMachina)
• Dave Batton [Added Friday, though I met him before the Keynote]
• Ken Ferry (kongtomorrow)
• Andy Kim [Added Friday]
• Paul Kim (mr_noodle) [Added Friday, though I met him after the Keynote]
• Devin Lane (DevG5)
• Gus Mueller (ccgus) [Added Friday]
• Scott Stevenson [Added Friday; I’d met him previously at CocoaHeads]
• Many Adium fans (thanks for your kind words, everyone!)

Bloggers I met at the WWDC Bash

• Kevin Ballard (Eridius)
• Blake C. (who is apparently a big fan—woot!)
• Steven Frank
• Daniel Jalkut (dcj)
• Jonathan Rentzsch (rentzsch)
• Cabel Sasser
• Jonathan Wight (schwa)
• Dan Wood

Bloggers I met at CocoaHeads

• Scott Stevenson

The audience was SRO, so David and I (along with Devin and Michael Gorbach) just went off to The Studio and hacked code. After the meeting, I went up to Scott, and we shook hands and that was it. My guess is that it was a busy night and he wanted sleep.

People I’ve seen at WWDC, but did not talk to

• Aaron Hillegass
• Uli Kusterer
• Wil Shipley
• Brent Simmons
• Quinn
• George Warner

People I saw at the WWDC Bash, but did not talk to

• john calhoun
• Martin Ott (I think he saw my Adium shirt and said “look, Adium!”, but it could just be wishful hearing, considering Ozomatli was blaring at the time)
• Some other people I’m totally blanking on

They’re calling it “iTunes Plus”, and the current Single-of-the-Week is available in it. Took them long enough—yesterday was the last Tuesday in May, and they didn’t even get done with it until today.

Ah, well. At least it’s finally here. Woo-hoo!

By the way, you need to update to iTunes 7.2 and agree to the iTS terms and conditions again to turn on iTunes Plus. The actual T&C haven’t changed, but the Terms of Sale have.

Compare this translation interface (what I’ve been using):

Babel Fish (in Camino, because none of my other browsers work with it)

to this one (what I should be using):

I used to hate Sherlock under Mac OS 9—I went so far as to custom-install Find File from Mac OS 8.5. But Sherlock under Mac OS X is pure awesome.

Now, if they kill it in a future OS version, I’ll be sad. And I may end up cherry-picking from the old OS disc again.

Anybody who’s ever needed to work with virtual key-codes—especially to program a hotkey—has had the problem of looking up the key-code for a specific key. The usual solution is to fire up Peter Maurer’s Key Codes.app and press the key, but wouldn’t it be nice to look it up in a handy table that you could print out?

There actually is such a table, but it’s well-hidden in the Apple documentation. Mac OS X uses the same virtual key-codes that it used for the legendary Apple Extended Keyboard. Thus, the table in Inside Macintosh: Text still applies.

The problem is the asstastic low-resolution JPEG scan of the table that Apple provides in the online version of IM:Tx:

Good luck with that!

So I did some poking. It turns out that there is a PDF version of IM:Tx on the ADC website—complete with a vector, rather than raster, table. Unfortunately, opening a PDF and jumping to figure C-2 is no easier than firing up Key Codes and pressing the key.

So here’s a handy-dandy crop of the PDF (with attribution added). Because it’s a vector image, the key codes in this version should be clearly readable at any resolution. Here’s what it looks like:

In case you’re wondering, I cropped it by copying the figure in Preview, then pasting into Lineform, which enabled me to add the attribution under the figure heading.

In a previous version of this post, I provided a 600 dpi PNG version of the key-codes table. In making that one, Lineform also enabled me to export to PNG at 600dpi rather than 72.

UPDATE 2008-11-29: Replaced the PNG image with a PDF document.

Here is a rundown of every file format you can use to distribute your software, along with their advantages and disadvantages. They are listed in ascending order of effectiveness.

In case you’re wondering, 7-zip and StuffIt X are not listed here because nobody has decompressors for them. I wrote this list for the context of software distribution; the days of saying “You will need StuffIt Expander to open this file” are long over.

I bring this up because, having in mind my objections above to disk images, I released EasyMD5 as a zip archive. I did it this way because EasyMD5 is targeted at Adium users (specifically, those who have problems downloading Adium); experience has proven that I can’t assume that an Adium user will know how to deal with disk images. Everybody knows how to handle zip archives (hello, Chris!), so I made it a zip archive.

I hadn’t yet done the study of file sizes that I did and published yesterday. Now that I have, later today, I’ll replace the zip archive with an internet-enabled disk image.

UPDATE 11:37: Added mentions of Paul Kim’s proposal of a runtime check for the disk image nature, and clarified the Lazyweb request.

UPDATE 20:47: Updated to include comments from Sven-S. Porst and Michael Tsai.

…you didn’t.

Apple has extended the WWDC early registration deadline to May 11.

1. swab

   swab(3) is a function that copies some bytes from one location to another, swapping each pair of bytes during the copy. Handy for structures.

   It has a feature that isn’t mentioned in the Darwin manpage for swab: If you pass a negative size, it does not swap. I have no idea why this magic behavior was added; if you want a swab that doesn’t swap bytes, just use bcopy. I shake my head at this use of a magic argument.

2. ntohs, htons, ntohl, htonl

   These four functions swap the bytes of a 16-bit (‘s’) or 32-bit (‘l’, in ignorance of LP64) integer and return the transformed value.

   They are mainly used in network-I/O contexts, as they transform between network byte order (big-endian) and host byte order (whatever you’re running). But there’s nothing stopping you from using them for any other 16-bit/32-bit integral byte-swapping.

3. OSByteOrder (Darwin)

   The Darwin kernel provides a number of handy-dandy macros for byte-swapping:

   • OSSwap{Const}?Int{16,32,64}
   • OSSwap{Host,Big,Little}To{Host,Big,Little}{Const}?Int{16,32,64}

   The {Host,Big,Little}To{Host,Big,Little} functions swap conditionally; the others always swap.

   According to the Universal Binary Programming Guidelines, it is safe to use these in applications.

4. Core Foundation

   CF’s Byte-Order Utilities provide the same facilities as OSByteOrder, with a couple of twists:

   • The implementation uses assembly language when the environment is GCC on either PowerPC or x86. This is theoretically faster than OSByteOrder’s pure-C implementation. (CF falls back on pure C in all other environments.)
   • CF adds support for byte-swapping 32-bit and 64-bit floating-point numbers.

5. Foundation

   Foundation’s byte-order functions bear all the same capabilities as the CF Byte-Order Utilities. In fact, they are implemented with them.

6. NeXT byte-order utilities

   These utilities are equivalent to the Foundation functions, except that they are implemented using the OSByteOrder utilities. They are declared in <architecture/byte_order.h>.

7. Core Endian

   

   I think that the “Core Endian” name itself is new in Panther. Three functions in the API have a “CoreEndian” prefix, and are marked as new in Panther, whereas the others have simply “Endian”, and are marked as having existed since 10.0. This suggests to me that the entire API was branded “Core Endian” in 10.3, with the older functions subsumed by it.

   The new functions have to do with “flipper” callbacks, which you can install so that things like Apple Event Manager can DTRT with your custom data types. The older functions are plain byte-swapping utilities, just like all the other APIs described here, and exist mainly for the benefit of QuickTime users (they exist on Windows, too, through QuickTime).

This bug is iTunes does not FNNotify after moving items to the Trash. It was filed on 2007-04-13 at 19:56 PDT.

(more…)

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.

(more…)

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

(more…)

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.

(more…)

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