Archive for the 'Mac OS X' Category

A possible solution to the stolen-focus problem

Wednesday, December 5th, 2007

Jeff Atwood posted an article today titled Please Don’t Steal My Focus, about dialog boxes coming up while you’re typing.

The problem, in a nutshell, is that these dialog boxes steal keyboard focus. Sometimes it’s for a text field; sometimes it’s just for Full Keyboard Access (i.e., a button gets the focus—usually, these are alert boxes). Regardless of what control gets keyboard focus, it gets it by stealing it from your app, which is a problem if the user is typing when that happens. Most likely, either some text will go to the wrong place, or the dialog box will beep for every keystroke; either result will annoy the user.

We’ve had the same problem for a long time in Adium: we’ll throw up a dialog box, but the user is typing a message, and notices that half his message isn’t in the inputline. We believe we’ve fixed most of these, but we still get complaints about this problem from time to time.

Currently, we solve the problem by simply ordering the dialog front without making it key. This works for most people, but it doesn’t help people who really do need Full Keyboard Access, since you have to click on the dialog box to dismiss it (or make it key) if it isn’t key. We (by which I mean Mac programmers, not just Adium) need a better solution.

I propose an addition to NSAlert. Here’s how it would work:

  1. From the creation of the NSAlert instance, it watches for key events.
  2. When any key goes down, the alert resets the timer (if one is present) and sets a flag.
  3. When all keys are up, the alert creates and starts the timer (with an interval of, say, a couple of seconds).
  4. If you tell the alert to show, it checks the flag. If the flag is clear, it simply performs makeKeyAndOrderFront: like usual. If the flag is set, it only orders front, and it sets a second flag.
  5. When the timer fires, the alert clears the first flag, and if the second flag is set, makes itself key.

From the user’s perspective, this results in the alert waiting a couple of seconds for them to pause in their typing before it takes keyboard focus.

Does anybody know of an existing free implementation of this, or plan to write it themselves?

How to make X11 work better on Leopard

Monday, November 5th, 2007

On the X.org XDarwin page, Ben Byer of the XDarwin team is providing a fixed-up version of Leopard’s X11 for download. I’ve installed it and I’m pleased so far.

It’s a mixed bag so far, but then, that’s why it’s alpha. Let’s go through the items from my X11 on Leopard is broken post and see how far they’ve come in the week since the Leopard launch. I’ll list the fixed ones first, then the unfixed ones:

  • Option-click [and ⌘-click] is broken

    Fixed. Both work as expected: option-click middle-clicks and ⌘-click right-clicks.

  • Windows don’t stop at the menu bar

    Fixed.

  • Applications menu doesn’t work with arguments

    Fixed.

  • xterm ignores .Xdefaults when invoked through the Applications menu

    (I never got around to adding this one to the previous post; sorry.) Fixed.

  • Wireshark is broken (from the comments on the previous post)

    Fixed, according to Bert JW Regeer’s comment.


  • .xinitrc is ignored (sort of)

    Not fixed.

  • xterm ignores .Xdefaults when invoked by login

    Not fixed.

  • Two X11s

    Not fixed. I’m not sure that this is fixable; it’s just an unfortunate side effect of the factorization of X11 into an xterm-launcher and a server.

  • It still looks like Tiger

    Not fixed.

  • X11 doesn’t activate like it’s supposed to (reported by Alan Boyd)

    Not fixed.

New Leopard Dock separator

Monday, October 29th, 2007

If you’re like me, you reject Leopard’s new 3D-looking Dock out of hand, preferring the new 2D smoke look also introduced in Leopard. All it takes is a simple defaults command to switch the Dock from 3D to 2D mode.

I think the new 2D Dock looks a lot cooler than the Dock in Tiger, except for one part that, for me, sticks out like a sore thumb.

It’s the separator between the applications and not-applications sections.

Here’s what Tiger’s separator looks like:

It's just a black line completely bisecting the Dock's background.

Simple; gets the job done.

Leopard, on the other hand, has a goofy-looking zebra crossing instead:

A zebra crossing, in case you don't know, is a series of white (or in this case, light gray) lines. It's named for the alternating black and white stripes of the zebra, which the zebra crossing vaguely resembles.

I can’t have that. So I fired up Lineform and created a new separator that I think looks a lot better:

My separator is a glowing white line.

Obviously, it’s modeled after the white LEDs that have replaced the black arrowheads to mean “application is running”.

In case you prefer this separator as much as I do, here’s how to install it:

  1. Download this image. I’ll assume you downloaded it to ~/Downloads.
  2. If you keep your Dock on the left or right edge of the screen, open the image in Preview and rotate it.
    • If your Dock is on the right edge, rotate the image left (⌘L).
    • If your Dock is on the left edge, rotate the image right (⌘R).
  3. Rename the image file. If your Dock is on the bottom, name it separatorstraight.png; otherwise, name it separatorstraight-horizontal.png.
  4. Open a second Finder window.
  5. Hit ⇧⌘G and go to /System/Library/CoreServices/Dock.app/Contents/Resources.
  6. Make a backup of the separatorstraight.png or separatorstraight-horizontal.png file from that folder.
  7. Move (⌘-drag) the image file from ~/Downloads to the Resources folder.
  8. Authenticate, if necessary.
  9. Open a terminal window and killall Dock. The Dock will relaunch automatically.

I haven’t made a 3D version. If you want one, post a comment. It shouldn’t be too hard to make, thanks to vector graphics.

X11 on Leopard is broken

Monday, October 29th, 2007

See also the follow-up: How to make X11 work better on Leopard.

In Leopard, Apple switched from XFree86 to X.org for its X11 implementation. This caused a few things to break.

Some of these are legitimate brokenness; some of these are just changes that break people’s expectations. I’ll attempt to list them all here.

.xinitrc is ignored (sort of)

In Tiger, when you launch X11, it runs .xinitrc, and .xinitrc runs xterm (unless you comment that line out).

In Leopard, X11.app is just a launcher. All it does is run /usr/bin/login -pf $USER /usr/X11/bin/xterm. In other words, its only purpose is to run xterm (semi-)directly, by itself—it’s not the actual X11 server anymore. When xterm starts, launchd sees it, notices that xterm requires X11, and launches the real X11 server (/usr/X11/X11.app) automatically. The X11 server then runs .xinitrc—but by this time, xterm is already running, so no changes in the .xinitrc can affect it.

This may be just an architectural change: You can’t rely on .xinitrc having been run by the time xterm is running. If not, it’s a bug: .xinitrc is supposed to have completed before any processes that use X11 begin running. I don’t know enough about X11 to know which is the correct behavior.

xterm ignores .Xdefaults when invoked by login

As mentioned above, the X11 launcher does its magic by invoking xterm through login. Unfortunately, when xterm is invoked as a login process (argv[0] starts with '-'), it ignores the contents of your .Xdefaults file—no custom fonts, no custom geometry, nothing; just a stock 80×24 black-on-white terminal.

I’ve created a different launcher that doesn’t go through login in order to work around the problem. I call it xterm.app. Since it doesn’t use login, xterm isn’t invoked as a login process, so it uses .Xdefaults, as it should.

Two X11s

X11’s new two-factor design is similar to the design of the mouse-based app launcher Sapiens. Like Sapiens, X11 now consists of a front-end launcher app and a hidden back-end application.

As with Sapiens, this gets confusing if you put the front-end launcher in your Dock, because when you click that tile, two things happen:

  1. That application exits immediately after you start xterm. Its little white LED comes on for just a fraction of a second.
  2. When xterm starts, launchd starts the back-end app to support it. The back-end app isn’t an LSUIElement, so it gets its own Dock icon.

The idea is that you should be able to simply launch an app that requires X11, and X11 will start automatically. If you use xterm as your terminal, and don’t use any other X apps (for which purpose you always had to launch X11.app directly), the best replacement (currently) is my app.

Option-click is broken

Laptops don’t have a middle mouse button, which you need if you want to paste into an X11 window. Thus, those of us with laptops have traditionally used X11’s “Emulate three-button mouse” feature, which maps option-click to middle-click and ⌘-click to right-click.

Unfortunately, this is broken in Leopard. Option-click does nothing; in xterm, ⌘-clicking on the scroll bar is acting like middle-clicking should, and ⌘-clicking on the terminal text area itself seems to do nothing but clear it.

It still looks like Tiger

quartz-wm draws X11 title bars with the Panther/Tiger appearance, rather than the new, darker Leopard appearance. It also has Tiger-sized rather than Leopard-sized drop shadows.

Windows don’t stop at the menu bar

You can’t move a regular Aqua window up underneath the menubar. But you can do this with an X11 window. It’s possible to become unable to recover the window this way.

Applications menu doesn’t work with arguments

Added at 15:44 PDT.

Apple’s X11 has always had an Applications menu that serves as a quick launcher for X11 programs. In Tiger, this launcher did the right thing with command-line arguments; either it went through the shell (perhaps using system(3)), or it split up the arguments and passed them separately to exec(3).

Leopard’s Applications menu is broken: It takes the entire command line you defined and passes it as one argument to execvp. It doesn’t know of any program by that suspiciously-long name, so the launch fails and you get an error message in the Console log.

Can’t drag a window to another screen

Paul Thomas mentions this in a comment here, but my friend Alan Boyd has more details:

It seems impossible to move an X11 window on to another monitor. The window itself is able to cross the boundary, but the mouse pointer is not. As a result, the entire window cannot be moved across. I’ve tried doing it in two steps, but once the window is placed on the boundary, it is not allowed to travel any further away from the original monitor.

X11 doesn’t activate like it’s supposed to

More from Alan’s post:

When launching X11 the menu bar is not set up correctly. Instead, the menu bar from the application that was active when X11 was launched is shown, rather than X11’s own menu bar. Clicking on the window that opens seems to rectify this problem.

Basically, X11 doesn’t come to the front when you launch the first process that requires it, like it should.

My xterm.app utility works around this bug, too: it runs its activate application "X11" script twice in order to make sure it comes to the front.


I will update this post as I find new bugs, and as I file Radar reports for these.

They Fixed the Leopard Folders… or not

Wednesday, October 17th, 2007

Last month, Brandon Walkin wrote an analysis of why Leopard’s new folder icons are broken.

Point number 2 is that Apple has removed all color from the distinguishing marks on folder icons. For example (cropped from one of his images):

Leopard's new Public Folder icon still has the old crosswalk sign on a folder, but now it's just embossed into the imaginary paper of the folder, rather than superimposed in full color.

Bland, isn’t it? And hard to spot at a glance among a folder full of other special folders, such as the folders in your Home folder.

So I was pleased to see this image on Apple’s page for the Leopard File Sharing features:

The Sharing pane in System Preferences has a giant Public folder icon, but with the full-color crosswalk sign restored.

Woo-hoo! They brought the colors back!

But then I looked more closely:

This is a close-up of the aforementioned Sharing pane. In the pane is a list of shared folders; two of the folders in the screenshot have special folder icons, and we can plainly see that these real folder icons are still embossed.

If they know how much cooler it looks with color, as evidenced by using it with color on the big image, then why not put the color back in the real icons?

From the reusable-slogans department

Tuesday, October 16th, 2007

Apple, in 1998, about Mac OS 8.5:

Get a new Mac for $99.

Apple, in 2007, about Mac OS X 10.5:

Add a new Mac to your Mac.

Also, both versions end in .5. Freaky!

What do the periodic scripts do?

Monday, October 15th, 2007

Mac OS X includes three scripts that run at different periodic intervals. There are a number of utilities—such as Macaroni (currently on sale through Friday), Cocktail, MacJanitor, and Anacron—that will run these scripts at your command or move them to a more convenient schedule (since we don’t all leave our Macs running all night). (UPDATE 2007-10-16 07:31: Not that that’s necessary. Tiger will run the periodic scripts at next opportunity, if the regularly scheduled time is missed. See Augie Fackler’s comment below.)

The problem is that these scripts have become voodoo, like zapping the PRAM or rebuilding the Desktop file or repairing permissions. People run them for no reason and any reason. Something wrong? Make sure you’ve run the periodic scripts!

The truth is: The periodic scripts won’t fix anything. At best, they’ll save you a very tiny bit of disk space.

Here, in plain English, is the full list of everything the periodic scripts do as of Mac OS X 10.4.10.

There are three scripts: “daily” runs at 0315 every morning, “weekly” runs at 0315 every Saturday, and “monthly” runs at 0530 on the first day of every month.

Daily

  • Clean out crash logs older than 60 days.
  • Delete temporary files used by the rwho command older than 7 days. If you don’t use rwho, this doesn’t affect you. (It doesn’t even seem to be enabled on my system. It may only be in use on Mac OS X Server.)
  • Cleans out the /tmp (temporary files) directory
  • Cleans out old temporary files for faxes.
  • Removes system messages older than 21 days. I don’t know of anything that actually sends a system message by the mechanism involved.
  • Sweeps up old system accounting statistics. These are solely for monitoring by a human administrator; they aren’t needed by the system. This feature may not even exist on Mac OS X, or may be only on Mac OS X Server; the folder that this cleans out doesn’t even exist on my system.
  • Makes a backup copy of the NetInfo database, which contains information such as Mac OS X account details. Unless you frequently add and remove such accounts, you probably don’t need to worry about making sure this runs.
  • Lists several things in the output:
    • Disks, with amounts of space used and free (df -k -l)
    • Recent backups made with the dump command
    • The mail queue (is your Mac a mail server? probably not, in which case this doesn’t do anything)
    • Network interfaces (Ethernet ports, AirPort cards, IP over FireWire), with their IP addresses and counts of packets sent and received
    • Uptime for all systems on the network, if rwho is active (it isn’t, on my system)
  • Rotates system.log. The script deletes system.log.9.gz, renames system.log.8.gz to system.log.9.gz, renames system.log.7.gz to system.log.8.gz, and so on. It then compresses the current system.log, renaming it to system.log.0.gz in the same step, and starts a new system.log.

Weekly

  • Updates the locate database. locate is just a find-files command.
  • Updates the whatis database. whatis is just a command that briefly describes other commands. For example, “whatis locate” describes locate as “find files”.
  • Rotates the log files of the FTP server, DNS, print server, mail server, NetInfo server, Xserve hardware-monitoring server, firewall, PPP (dial-up internet—remember that?) system, and security server. (The security server is responsible for authorization dialogs, the Keychain, and the sudo command.) Of these, most Macs have only DNS, NetInfo, and the security server actually in use; the others are not even running.
  • Rotates the log files of the web server. If you don’t have “Personal Web Sharing” (also known as Apache) turned on, this doesn’t affect you.

Monthly

  • Reports in the output how much time each user on the system has spent in a terminal in the past month (as a running count of days spent—it’s not broken down by weekdays or anything like that).
  • Rotates the file used by ac to tally up how much time each user is spending in a terminal (see previous list item).
  • Rotates the Installer log. I think this also covers Software Updates, but I’m not sure. It doesn’t cover third-party application updates.
  • Rotates the fax logs.

While all of that is nice to do once in awhile, you don’t need to do it and it won’t fix anything. UPDATE 2007-10-16 07:31: Further, as Augie points out in his comment, Tiger will run the periodic scripts at the next opportunity anyway, so there is NO reason to run them yourself.

A productive Apple Bug Friday

Saturday, October 13th, 2007

I finally got around to filing a lot of the Leopard bugs I racked up after WWDC:

All told, I filed 15 of them.

Too bad I did it so late, though. It’s probably GM already.

Ghostwriter has invaded my menubar!

Thursday, September 27th, 2007

All the lowercase e's in my menubar are missing from all of OmniWeb's menus (except for Help, strangely enough). A blank space shows instead.

WTF?

And no, it’s not just in OmniWeb (or, for that matter, my menubar):

Same goes for capital F and lowercase L in Mail's Activity Viewer window.

WWDC 2007 session videos are out

Monday, July 30th, 2007

If you attended WWDC, you can head over to ADC on iTunes and see what you missed.

Code signing: Not as new as you think

Tuesday, July 3rd, 2007

Code signing is new in Leopard, right?

Right?

No, actually; it’s much older, as I found out while responding to a question on programming.reddit. In my results for a Google search that I did, I stumbled over a link to TN1176, which mentions the addition of code signing.

TN1176 is the release notes for Mac OS 9.

The technote doesn’t actually say much. In fact, I can go ahead and quote it in full:

Apple Code Signing is a new technology in Mac OS 9
that allows applications, plug-ins, and content to be
signed by developers. Apple Code Signing Certificates
assure your customers of your identity and the integrity
of your products. For more information, please see the
Mac OS Security and Cryptography Web
site.

That site’s gone now, of course. Fortunately, the Wayback Machine saved a copy.

Screenshot of the icon for
Apple Verifier

Screenshot of the icon for
Apple Signer

The top link on that page is to the Security 2.0 SDK, which includes a lot of stuff relating to code signing. There’s a pair of utilities called Apple Signer and Apple Verifier, some API documentation, some sample code, some resource templates (remember those?), a library, and the debugging root certificate.

UPDATE 06:29: Apple Verifier actually comes with the OS, but Apple Signer is only available in the SDK.

If you’ve ever seen a 'sign' resource while hacking in ResEdit, now you know what it was.

Meet the new boss
Same as the old boss


Oh, and in case you’re wondering what the Signer and Verifier applications look like:

This screenshot shows Apple Signer generating a signature for the SDK archive.
Signer at work.

This screenshot shows Apple Signer verifying the same signature.
Signer can also verify.

This screenshot shows the result of Apple Signer's verification of the signature.
Result of verification.

This is a screenshot of the Apple Signer window that shows the contents of a certificate.Same window, but for a root certificate.
These are the certificates from the verification. The root cert is the “Issuer’s Certificate” for the other one.

This screenshot is of a dialog box that says “That application or control panel is not supported by Classic”.
This is why I didn’t explain the difference between Apple Signer’s Verify command and Apple Verifier: I don’t know, because this message comes up when I try to launch Apple Verifier. And no, I don’t know why the message comes up.

Apple Bug Friday! 63

Friday, June 22nd, 2007

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

(more…)

Apple Bug Friday! 62

Friday, June 22nd, 2007

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

(more…)

I’d forgotten how awesome Sherlock is

Sunday, May 27th, 2007

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

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

to this one (what I should be using):

Sherlock, with its text fields that take up almost the entire window.

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.

Virtual key-codes

Tuesday, May 22nd, 2007

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.

Disk images suck: An examination of why, and of the alternatives

Sunday, May 13th, 2007

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.

Disk image

Advantage:

Sandboxes the application: If it won’t work from the disk image, it probably sucks

Disadvantage:

Confuses the average user; they typically run the application from the disk image, then encounter problems when they try to delete the image file or (much later) run a Sparkle update


Back in March, an Adium user had a problem trying to perform the Sparkle update. It gave her an error:

“Update Error! Adium does not have permission to write to the application's directory! Are you running off a disk image? If not, ask your system administrator for help.”

This wouldn’t be so bad, except that she didn’t know what a disk image was, so she assumed that she was not running Adium from the disk image (I imagine she thought something like “surely I’d know what that was if I was using one”). She looked up the troubleshooting instructions in the Adium help (good), then critically misunderstood them (bad) with the result that she moved her Adium 2.0 folder out of the Application Support folder. (Don’t ask me to explain it. I don’t know, either.)

All this ultimately resulted from the fact that average users, including her, don’t recognize a disk image when they see it. They don’t expect a file to act as a drive.

The same non-obvious nature results in other problems: specifically, the error message “The operation cannot be completed because ‘SurfWriter-1.0.dmg’ is in use”. This occurs when the user tries to delete the disk image file without unmounting it first. Users who encounter this message end up contacting us (usually asking “how do i uninstall it”). This is only natural, because who would expect that a file is mounted, or that a file can be in use in another file?

It was then that I realized that disk images are not as great for the average user as I had previously believed.

You may be thinking “well, just put a background image with an arrow to an Applications folder”. We did that. It didn’t help this user.

The stories I heard from other developers suggest that people in general zero in on the application they want to use, without paying attention to anything else (e.g., arrows, help text, or symlinks). Besides, the questions I hear from the users via the feedback list suggest that users see the disk image window and think the application is already installed—they aren’t looking for or expecting installation instructions, so your big arrow means nothing to them.

I suspect that installers are partly to blame for that: I don’t know about Windows, but on Mac OS, installers would always open the folder containing the freshly-installed application, so that you could use it right away. I suspect that users mistake the disk image window for a freshly-installed-folder window.

Anyway, one solution to the tunnel-vision problem would be a “DRAG THIS OVER HERE” message in a big font—but that’s no good, because you can’t have localized background images. You’d have to pick one language, and hope that all your users know it, but anybody who doesn’t know the language you chose wouldn’t benefit from your nice obnoxiously big text. (On the other hand, this provides a second reason for unilingual builds: One disk image per language, with both the background and the application localized in that language only. Hmmmm.)

Another solution is a runtime check whether the app is running from the disk image. You’ll have to be careful with wording here, though—you need to be 100% sure that you’re running from a disk image, and write the alert text accordingly. There can be no vacillation like in the Adium alert box (which vacillates because it’s caused by a simple permission failure, not an actual search for the disk image nature); it must be a statement, not a question. And of course, you must tell the user the remedy (copy the app, then run the copy, then eject the disk image file and never mount it again).

One last point: bzip2 compression (-format UDBZ) requires Tiger. Your disk image won’t mount on any earlier version of the operating system; your users will think it’s corrupt, since that’s what the error message suggests, and they’ll contact you with that assumption. This probably doesn’t matter anymore, since the Omni Group’s software-update statistics say that 98.4% of users are on Tiger (as of 2007-05-12), but if you still support users of earlier OS versions, you need to use zlib compression (-format UDZO) instead.

Tarball

Advantages:

Smaller than disk images; unpacks into a folder or bare application

Disadvantage:

Safari mishandles bzip2’d tarballs pretty spectacularly; one must gzip one’s tarballs to avoid that problem, but then one loses out on yummy bzip compression


Safari, for some reason, saves a bzip2’d tarball as “foo.tbz.tar”, even though it is still a tbz. Unpacking it results in a tar archive named “foo.tbz”, followed by the folder that the tar archive exists to hold. So the actual unpacking behavior works as expected, but it badly screws up the filenames.

This all works correctly with tgz, but of course you can’t use gzip and have bzip2 compression.

Zip archive

Advantages:

Unpacks into a folder or bare application; can be created from the Finder

Disadvantage:

Bigger than anything else


Zip archives are the easiest to create, because you can simply right-click on the contents and choose “Create Archive of SurfWriter.app”. Unfortunately, the compression ratio is just not there; I consider zip files obsolete for this reason. You should be optimizing for your users’ download time, not your own compression time.

Internet-enabled disk image

Advantage:

Unpacks into a folder or bare application for the average user (Safari with “Open Safe Files” turned on); perfectly normal for everybody else

Disadvantages:

Won’t work the same way twice (when the user goes to unpack it the second time, it behaves as a perfectly normal disk image, with the attendant confusing UI); hard to create; unpacks slowly


This is the best of both worlds. The average user uses Safari and has “Open Safe Files” turned on; in this case, Safari will unpack the disk image just as if it were a tarball or zip archive. The sort of person who turns “Open Safe Files” off, or uses a different browser, is also the sort of person who can handle a normal disk image, and will indeed be handling it because that’s how the disk image behaves in those cases. The extremely-rare exceptions can be handled by the aforementioned runtime check.

They’re the hardest to create because you need to use a Terminal command (hdiutil internet-enable SurfWriter-1.0.dmg) to set the internet-enabled bit on the image. Dear Lazyweb: Please make a contextual menu item that generates an internet-enabled UDBZ disk image directly from a folder in one step, the same way I can make a zip archive in one step. (Michael Tsai, in a comment, says that his $20 DropDMG utility can do this, with Automator‘s help.)

Another disadvantage is that a disk image, internet-enabled or otherwise, takes much longer to process than a zip archive. I think this is because of the verification step, but the user won’t care. I think people will put up with it for most archives, but if your archive is huge (let’s say over 50 MiB), you may want to switch to a zip or tarball to save time. Of course, you’ll be sacrificing part of your bandwidth bill for that. (Thanks to Sven-S. Porst for bringing this up in another comment.)

Also, the format notes (UDBZ vs UDZO) for disk image above apply to internet-enabled disk images as well. Just in case you were wondering.

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.

How do I swap thy bytes? Let me count the ways

Saturday, April 28th, 2007
  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

    Core Endian logo that I made up.

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

Wit and wisdom from the manpages

Tuesday, April 17th, 2007

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 and Services are your friends

Thursday, April 12th, 2007

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.

A novel way to reduce the size of a grayscale PNG file

Sunday, April 8th, 2007

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.