Idle Time

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?

This casts Apple’s recent keyboards in a whole new light for me.

(Image courtesy of Patrick Gibson. I cropped and spotlit it using Acorn.)

I originally saw this keyboard on Wikipedia, but Patrick was nice enough to take a better photo—thanks!

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.

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:

Simple; gets the job done.

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

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

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.

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.

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

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:

Woo-hoo! They brought the colors back!

But then I looked more closely:

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?

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!

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.

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

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

From QA1420:

(In case you don’t get it, here’s the reference.)

They finally started selling something that I want to buy.

Almost since the iTunes Music Store first opened, I’ve been a customer of the iTunes Store. 99¢ a song is fine by me, and I love paying by the song. There are few albums so consistently good that I’ll buy the whole thing.

Then iTunes Plus started, and I immediately switched over. Sure, it’s 30¢ extra, but I pay that 30¢ as a statement against DRM.

Then came the Amazon MP3 Store.

Amazon sells plain old MP3s, at roughly 256 kbps VBR (in order that nobody can complain about the encoding quality). Since they’re plain old MP3s, there’s no DRM.

Even better, Amazon beats iTunes’ prices: 89–99¢ per song. iTunes charges $1.29 (remember, no DRM, so the proper comparison is to iTunes Plus rather than to non-Plus).

So, in short:

• The encoding is almost as good as or better than iTunes.
• The price is the same as or less than iTunes.
• Amazon’s MP3s are never DRMed, whereas iTunes’ MPEG-4s are usually DRMed.

Like Simone, I shall buy from Amazon first from now on. (I haven’t switched away from iTunes; they’ll continue to get my business for songs that Amazon doesn’t carry. But, unfortunately for Apple, I expect that set to diminish.) Take notice of this, Apple—get the record labels to let you lower your prices, or you will lose serious market share to Amazon.

Just in case you’re wondering…

The Amazon MP3 Store works by downloading a file in a special format: .amz. This is a document for the Amazon MP3 Downloader application. (In case you’re wondering, the contents are some binary data, which may just be ciphertext of some sort, encoded in base64.)

The reason they do this is so that it can download the MP3s into a subfolder of your Music folder, rather than your usual Downloads folder (normally your Desktop). That’s good, but it has two downsides:

1. You need a Windows or Mac OS X PC to download MP3s from Amazon, even though the MP3s themselves will play anywhere.
2. If your browser is set not to auto-open files, or doesn’t trust the Amazon MP3 Downloader, then you may be sitting there for a moment wondering why the Downloader is not doing anything.

My suggestion to Amazon would be to switch to a custom URL scheme, rather than a custom file format. I don’t know about Windows, but this would certainly make it much easier on the Mac, since the custom URL scheme will always work. (It won’t help the non-Mac non-Windows users, though, since you still need the Amazon MP3 Downloader to handle the custom URL.)

WTF?

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

Now on iTunes: An endcap with various songs from commercials. They’ve done this before, but this time, the first four tracks are from recent Apple commercials, including the one from the iPhone commercials.

On the general options pane, there is a field labeled “Tagline”:

The value shown in that field is WRONG WRONG WRONG!

You see, that’s actually supposed to be HTML—or at least, such is the implication of the Atom template’s use of bloginfo_rss to get the description. The difference between {get_,}bloginfo_rss and {get_,}bloginfo is that the _rss versions call strip_tags to take out any HTML and escape any non-HTML characters, such as &.

That wouldn’t be so bad if strip_tags worked properly, but it doesn’t—not on this host, at least. It leaves the second & in the above example unescaped. (“OK, I escaped that one. It must be the only one. I’m off to Subway!”)

As if that wasn’t bad enough, WordPress doesn’t escape the tagline field’s value when putting it back into the field the next time you load up the Options pane. (It does if it’s plain text, but not if it’s HTML. Go figure.) So if you click “Update Options” again, your HTML goes bye-bye. You need to remember to re-escape it every time you save the General Options.

(Given that, maybe it’s not supposed to be HTML after all, and the use of bloginfo_rss in the Atom 0.3 template is a bug.)

Want to know how I found this out? Because the RSS reader in Safari 2 (I don’t use 3) was critically failing on the Atom feed. It was slurring posts together once it saw that an ampersand was not escaped.

Relevant versions:

• WordPress 2.1.3
• PHP 5.1.4 or so (I have no idea what version is actually running the blogs)
• Safari 2.0.4/419.3

Previous assignment of function keys:

This made (some) sense as the explanation for iLife 2008’s refusal to allow you to assign these keys to its functions.

New assignment of function keys on otherwise-yummy new keyboards (yes, both of them):

WTF?

* As named in iTunes’ AppleScript dictionary. ↶

This bug is iTunes viewport pinned to top of selection when selection is at top of viewport. It was filed on 2007-08-02 at 10:31 PDT.

(more…)

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

UPDATE 17:05 PDT: My theories have been disproven by my sharp commenters. See the comments for the true explanation. Thanks, guys!

Quoth the DFLL:

Apple Reports Third Quarter Results ★

…

270,000 iPhones sold in the first two days, and Jobs is quoted in the PR saying “we hope to sell our one-millionth iPhone by the end of its first full quarter of sales”.

Incorrect.

Here’s what Apple’s unaudited summary data (linked from that press release) says:

So they sold 270,000 of “iPhone and Related Products and Services”. Suppose that all of those are $499 (which we know is false):

499 × 270,000 = 134,730,000

$134M! That’s a long way from $5M.

The explanation is in that footnote 6:

(6) Consists of iPhones and Apple-branded and third-party iPhone accessories.

So if you bought an iPhone and a case, you effectively bought two iPhones for the purpose of that column. More accurately, you bought an iPhone (+1) and a Related Product (+1), for a total of +2.

I suspect the real number of iPhones, not counting accessories, is much, much closer to AT&T’s 146,000-activations number (since very few people will buy an iPhone and not activate it).

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.

Apple Verifier

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:

Signer at work.

Signer can also verify.

Result of verification.

These are the certificates from the verification. The root cert is the “Issuer’s Certificate” for the other one.

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.