1. Hit the key. (E.g. F12 for Dashboard.)
2. Use the mode.
3. Hit the key again when you’re done.

It ends up there’s a second way to use these shortcuts: press-and-hold:

1. Press and hold the key down.
2. Use the mode.
3. Release the key when you’re done.

I’m not going to argue that this saves any time or effort, but ever since I learned this trick, I’ve been using it whenever I invoke Dashboard and the application windows mode of Exposé. I mean, if you’re going to be using some Dashboard widget for a while, sure, you’ll want to use the regular “tap the key” mechanism — but if you just want to glance at one or more status-displaying widgets (e.g. Weather), the press-and-hold mechanism feels just right. It’s also worth noting that the Exposé shortcuts work like this in Mac OS X 10.3, too.

(Thanks to Dave Giunta for the tip.)

From the osascript man page:

Any arguments following the script will be passed as a list of strings to
the direct parameter of the ``run'' handler.  For example:

      a.scpt:
      on run argv
          return "hello, " & item 1 of argv & "."
      end run

      % osascript a.scpt world
      hello, world.

(Thanks to MacOSXHints.com.)

Apps that use ATSUI (Apple Type Services for Unicode Imaging) for text rendering get support for these advanced typographic features, including Pages, Keynote, and just about any app that uses the standard Cocoa text editing field.

This was all well and good, but wasn’t of much use to serious type users because AAT fonts are not widely produced by companies other than Apple. The de facto standard format for fonts with built-in advanced typographic features is OpenType.

The good news is that starting with Tiger, Mac OS X now automatically maps OpenType features to AAT features. This means if you have OpenType fonts installed, they now “just work” in apps that previously provided advanced typographic features only with AAT fonts. If you have any OpenType fonts installed (several excellent OpenType fonts are included with the Adobe Creative Suite, for example), you can try these features out in TextEdit. Open the Fonts panel, then open the Typography palette from the Font panel’s gear menu.

The Typography palette is contextually smart, only showing the features available for the current font. Apple doesn’t support as many OpenType features as Adobe’s own applications (which render text using their own cross-platform code), but it’s a terrific start.

(Thanks to Mark Simonson, Eric Allison, and Andreas Bachofen for the tip.)

(It’s even documented by a man page: type man WaitingForLoginWindow at a command-line prompt.)

The pace of the progress bar isn’t measuring anything — it’s just a guess as to how long it will take until loginwindow is ready. When loginwindow appears, it kills the WaitingForLoginWindow process. When it exits, WaitingForLoginWindow stores the number of seconds it ran in a text file here:

/var/db/loginwindow.boottime

The next time it runs, WaitingForLoginWindow uses the number of seconds stored in this file to set the duration and pace of its progress bar animation. Examine the contents of this file to see how long WaitingForLoginWindow ran the last time you booted. (On my iBook it was “20.711155”, but the next time I rebooted, it dropped to “4.642473”; on PowerMac G5s, it’s generally 1-3 seconds.)

The fun part is that you can launch WaitingForLoginWindow at any time. Using Terminal, execute:

/usr/libexec/WaitingForLoginWindow

Up pops the “Starting Mac OS X…” progress window. It’s harmless, pointless, but kind of fun. To quit it, you can type killall WaitingForLoginWindow at the command line.

When you’re playing around with it from the Terminal like this, WaitingForLoginWindow doesn’t write to the loginwindow.boottime file because it needs administrator privileges to do so. (If you launch it with sudo /var/db/loginwindow.boottime, however, it will write its run time duration to this file.) If you change the number of seconds in the /var/db/loginwindow.boottime file, you can change how fast the progress bar moves the next time you boot. This has no effect on how long it actually takes to boot — it just alters the pace of the progress bar.

(Thanks to Matt Deatherage and the 22 May 2005 issue of MDJ.)

For example, consider the display dialog command. Here’s a short example that simulates the error dialog from my PHP Syntax Checking script for BBEdit:

tell application "BBEdit"
  set msg to "Parse error: parse error in df_banner.inc on line 6"
  display dialog "PHP " & msg with icon caution ¬
      buttons {"OK"} default button 1
end tell

On Mac OS X 10.3, the resulting dialog box looked like this:

On Mac OS X 10.4, the resulting dialog box looks like this:

The biggest difference is that the icon is bigger and looks better, but you can also see Aqua’s stripes continue to fade away with each major release.

AppleScript 1.10 also introduces a new display alert command, which is similar to the display dialog command, but uses slightly different syntax, and provides a few additional options. The main difference is that it allows for both a bold-face title string, and a separate explanatory message.

tell application "BBEdit"
  set msg to "Parse error: parse error in df_banner.inc on line 6"
  display alert "PHP Syntax Error" message msg as warning
end tell

Its output looks much more like a standard Mac OS X dialog:

(The display alert command isn’t actually new; it has been a part of AppleScript-Studio since its inception. What’s new is that you can now use display alert in any script, not just in Studio apps.)

The text-editing field used by the display dialog command now uses the modern Mac OS X text rendering engine instead of the deprecated QuickDraw routines. Considering the following script:

display dialog "URL:" default answer "http://daringfireball.net/" ¬
    buttons {"Cancel", "Grab With HTTP Headers", "Grab"} ¬
    default button "Grab"

On 10.3, this produces:

On 10.4, it looks like this:

Note also that previously, when you specified three buttons in a call to display dialog, all three buttons would be the same width, determined by the length of the longest of the three labels. This produced unsightly results whenever the button labels were of varying lengths, and in some cases, as shown above, it resulted in the longest label being truncated.

A nice functional improvement in AppleScript 1.10 is that when using the listbox provided by the choose from list command, you can now use type-ahead to select an item in the list.

For more details on what’s new in AppleScript on Tiger, see the AppleScript 1.10 Release Notes.

For a long time, when I was filling out Web forms in Safari, I had to deal with the fact that, when I had copied text from another application and tried to paste it into a single-line text entry field in the Web form, if I had accidentally included the return character at the end of the line of text in the selection before I had copied it to the Clipboard, then when I pasted the contents of the Clipboard into the single-line text entry field, Safari would also insert the return character at the end of the line of text and make the single-line text field “scroll” down (even though it doesn’t have a vertical scroll bar, since it’s a single-line text entry field).

The end effect would be that, after pasting the contents of the Clipboard into the field, the field would look like it was still empty, because Safari would actually be showing the second line of text after the carriage return, which indeed would be empty. It was weird. You could still fix the problem by simply pressing the Delete key once after pasting the text, which would delete the return character and put the focus back on the first — and only — line of text in the field. But it was weird nonetheless.

Starting with Safari 2.0 (and 1.3 for Mac OS X 10.3.9), this is fixed. Any trailing returns are now automatically stripped when pasting text into single-line text fields in web pages. (Safari has always done this when pasting into the Location field in the Address Bar.)

Pierre also points out that it’s not just trailing returns that get stripped — if you paste multiple non-empty lines into a single-line text field, only the first line is actually pasted.

This is especially noticeable in the Dictionary widget, where the Baskerville typeface looks weak and wispy, and the italics are barely legible. Whereas in the Dictionary application, Baskerville looks great.

Compare the following screenshots, snapped with my font smoothing preference set to Medium. (If you’re using a CRT display to view these screenshots, the text in the Dictionary application might look like it has colored fringes; that’s because the Light / Medium / Strong smoothing options are intended for use on flat-panel LCD displays.)

The Dictionary widget:

The Dictionary application (with the font size decreased by one click, so as to match the size used by the widget):

(Brief interpolation on the above-pictured definition of “blog”: The italicized portion is not part of the definition itself; it’s example usage.)

One explanation for this might be that it’s because each widget process is a child process of the Dock, and the Dock does the same thing with the white-text-with-drop-shadow text it displays when you hover the mouse over an icon: it’s always rendered with Standard font smoothing. But even so, this raises the question as to why the Dock ignores this preference.

And, strangely, the “More Widgets…” button above the Widget Bar is rendered using Light / Medium / Strong font smoothing, but the widget names at the bottom of the Widget Bar are not.

Regardless of the explanation, the end result is that widgets do not look as nice as they could on flat-panel displays, which is really odd considering that “looking cool” is at least half the appeal of Dashboard.

(Thanks to Jussi Hagman).

In previous versions of Safari, however, those two shortcuts were used for switching between tabs (the Select Next Tab and Select Previous Tab menu items). Starting in Safari 2.0 (and also in Safari 1.3 for Mac OS X 10.3.9), the shortcuts for switching between tabs was changed to Command-{ and Command-}, which on a U.S. keyboard means typing Command-Shift-[ and Command-Shift-].

When the input focus is not on a text field, however, Safari still supports the old shortcuts for switching tabs.

Many people seem annoyed by this change, but it was the right thing for Apple to do. Or, perhaps better said: it was wrong for Safari ever to have used standard text-editing shortcuts for menu key shortcuts. And if you really can’t get used to the change, you can edit the menu key shortcuts in the Keyboard & Mouse panel in System Preferences.

Mac OS X offers three versions of sub-pixel rendering: Light, Medium, and Strong. Medium is described as “best for Flat Panel”, but in fact all three are only intended for flat panel displays — the sub-pixel rendering trick only works on LCDs.

(For more — much more — on the differences between these algorithms, see my article “Panther Text Rendering” from November 2003, shortly after Mac OS X 10.3 shipped.)

I’m inundated with email from readers who believe that with Tiger, Apple has significantly changed the way text is anti-aliased on-screen. This isn’t true. What has changed is that Apple has added a new option to the font-smoothing pop-up menu in the Appearance panel of System Preferences: “Automatic - best for main display”, and which is now the default setting for this preference. On CRTs, Automatic uses the Standard algorithm; on LCDs, it uses Medium.

Those who are noticing a profound difference in the way text is rendered on-screen are using flat-panel displays and have this preference set to “Automatic”. Previously, the default font-smoothing preference was “Standard”, even if you were using a flat-panel display.

I happen to think this change is a good one, producing better-looking on-screen text for flat-panel users. It’s obviously quite subjective, however, which is why Apple offers several options for this preference.

• You can drag a URL to Safari and it will open that URL in a new window.
• You can drag the URL for an XML feed to NetNewsWire 2, and it will create a new subscription to that feed.
• You can drag text to Safari, and it will perform a Google query on the text you dragged.
• You can drag any text clipping (regular text, URL, etc.) to BBEdit, and it will open a new document containing that text.

(Thanks to Jesper and Eric Blair.)

To toggle the display of the Widget Bar, use Command-= (equal sign). (Thanks to Daniel Bogan.)

[Update: Email from users of non-QWERTY keyboard layouts indicates that the shortcut for displaying the Widget Bar is Command plus the key to the left of Delete. That’s “=” on a U.S. keyboard, but on a French AZERTY layout, it’s the “-” (dash) key. I.e. the shortcut is tied to the key, not the character. (Thanks to David Latapie.)]

To refresh the frontmost widget, use Command-R.

An awful lot of casual Mac users are more or less hopelessly confused about when they need to double-click something to “open” it. (This applies to Windows users too, for that matter.) What tends to happen is that when they’re learning to use the computer, they’re tripped up by the entire concept of double-clicking — they either don’t click fast enough, or their coordination is poor and they move the mouse too much between the first and second clicks. Eventually they get the hang of it, but they never quite figure out the rules for when they need to double-click versus when a single-click will do, so what they end up doing is double-clicking just about everything.

In general, however, this confusion seldom matters. For example, you only need to single-click links in a web browser, but if you double-click them instead (as my father does), it doesn’t make any difference. Same goes for the Mac OS X Dock; a single-click launches an app, but a double-click does the same thing.

Not so with the Dashboard Widget Bar. Each click on a widget counts. Click once to open an instance of a widget. Click twice and you get two instances. Making matters much worse is that each instance of the widget opens in the exact same position on screen, so the most-recently-launched instance completely obscures the others, which means it looks like you’ve only launched one instance of the widget you double-clicked, even though you launched two.

Only when you move or close this widget will you discover that you’ve had another instance running underneath all along, which for most people will generate some measure of surprise and confusion.

Things Apple should do to fix this:

1. Double-clicks in the Widget Bar should launch a single instance of a widget. If you really want to launch two instances of a widget, just wait a second or two between clicks, or use drag-and-drop. A double-click on a widget in the Bar almost certainly means “open this once”.

2. When you open multiple instances of a single widget, each subsequent instance should be positioned on screen with a small diagonal offset from the previous instance so they don’t completely overlap — just like when you open a new document in any normal application.

That there is no master “Dashboard” process, and that the Dock is in fact the parent of every running Dashboard widget, helps explain the curious behavior of the Dashboard icon in the Dock. You can drag it off the Dock while it’s “running” and it will poof, even though Dashboard is still available and any running widgets remain running. Drag any other running application out of your Dock, and it springs back in to place as soon as you drop it. That’s because the Dashboard Dock icon is a sham; it’s just a proxy — something you can click on to activate Dashboard mode, and a place to put Dock menu commands related to Dashboard. The Dashboard Dock icon has nothing to do with whether any widgets are currently “running” or not — which makes it completely unlike every other app icon in the Dock.

If you do remove it from your Dock, you can put it back by dragging the “Dashboard.app” application from /Applications/. This creates the illusion that this Dashboard.app somehow “is” the Dashboard widget runtime environment. But it’s not. Remember, running widgets are owned by the Dock, not a separate Dashboard process. In fact, the bundle identifier for Dashboard.app is “com.apple.dashboardlauncher”, which name is quite apt. This is not a regular app that stays running: when you launch it, it switches you to Dashboard mode, and then quits. Again, you can see this with Activity Monitor — and that’s why Dashboard doesn’t appear in the Command-Tab switcher.

If you just want to refresh the contents of the Widget Bar to reflect any changes to your /Library/Widgets/ or ~/Library/Widgets/ folders, you can simply click the left/right buttons in the Widget Bar to page through the list. Doing so seems to pick up new/removed widgets. But this won’t help if you have a wide enough display that all of your installed widgets fit on one screen.

RFC 2229 defines the dictionary server protocol, section 5 of which pertains to “URL Specification”. It starts:

The DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:

dict://<user>;<auth>@<host>:<port>/d:<word>:<database>:<n>
dict://<user>;<auth>@<host>:<port>/m:<word>:<database>:<strat>:<n>

The “/d” syntax specifies the DEFINE command (section 3.2), whereas the “/m” specifies the MATCH command (section 3.3).

Some or all of “<user>;<auth>@”, “:<port>”, “<database>”, “<strat>”, and “<n>” may be omitted.

The DICT protocol, which is the main subject of the RFC, is about querying a dictionary server over the network. That’s not what Apple’s Dictionary does — the data source for Dictionary is a local database, not a server on the network. So most of the tokens in the URL scheme defined by the RFC aren’t applicable: <user>, <auth>, <host>, <port> aren’t needed.

Dictionary, however, seems to ignore all of them. Even the “/d:” and “/m:” actions, for “define” and “match”, which according to the RFC aren’t optional, aren’t supported by Dictionary.

So far as I can tell, the only URL format accepted by Dictionary is in the form:

dict:///<word>

Note that it requires three slashes, not two. For example:

dict:///paraphernalia

Seems simple enough. But what stinks is that the query must be an exact match. If you misspell the word, the look-up fails silently. The only thing that happens for a failed look-up from a URL is that the Dictionary app activates. For example, this won’t work:

dict:///insoucient

because “insouciant” is misspelled. In the regular Dictionary user interface, if you make a misspelling, it usually susses out what you meant and offers a suggestion. Type “insoucient” in the query field and you’ll be asked: “No entries found. Did you mean?”, with “insouciant” selected. All you need to do is hit Return to see the definition of “insouciant”.

It’d be nice to see a future update to Dictionary offer suggestions for queries that don’t match any entries in the database.

Update: Several readers report that this feature doesn’t seem to work at all. The problem is that even if you spell the search term correctly, these dict:// format URLs only work if the Dictionary app is already running. If it isn’t, opening a dict:// URL will launch Dictionary, but nothing will get looked up.

Update, 16 May: As of 10.4.1, widget scrollbars now work with mouse scrollwheels and two-finger trackpad scrolling, which means they no longer suck as bad as they used to. But they still don’t work as well as standard Aqua scrollbars. For example, they don’t support jump-to-here scrolling, neither by Option-clicking nor by supporting the setting in the Appearance panel of System Preferences.

“This pertains to 10.3.9 too, but Safari’s cookie display in 1.3 and 2.0 now intelligently sorts domains by ignoring any leading periods or ‘www’ prefixes, so a ‘www.bestbuy.com’ cookie appears next to a ‘bestbuy.com’ cookie in what usually turns out to be a staggeringly long list. Smoove.”

On the other hand, the Dock still does not take advantage of Fitts’s Law for drag-and-drop. When dragging items onto icons in the Dock, you can’t drag to the edge of the screen directly under the icon you’re targeting (or next to the icon, if, like any sensible person, you’ve positioned your Dock on the side of the screen). What’s crazy about this is that the Dock does take Fitts’s Law into account for clicking on icons — you can click under/next to an app’s icon in the Dock to activate it, but you can’t use those same pixels along the edge of the screen for drag-and-drop.

However, icon-related changes still don’t take effect immediately. For example, let’s say SubEthaEdit has claimed “.csv” files, but you’d rather have them open in BBEdit by default. Select one such file contained in a folder with several others, do a Get Info on it, change the “Open with” application to BBEdit, then click “Change All” to make BBEdit the default editor for “.csv” files.

The icons for all currently visible “.csv” files should update to reflect the change, but they don’t. The only icon the Finder updates is the one for the file you selected to Get Info on. But if you double-click one of the “.csv” files with a stale SubEthaEdit icon, it will in fact open in BBEdit. This bug has been around for the entire life of Mac OS X.

This was a major concern for web designers once word spread that Internet Explorer was no longer included; in previous versions of the OS, these Microsoft fonts were officially considered components of the IE installation. Verdana and Georgia are especially important — they’re the only high-quality screen fonts web designers can really count on for all Mac and Windows users.

My only gripe is that it doesn’t include the Enter key on iBook and PowerBook keyboards.

Gone, therefore, is the phrase “Welcome to Macintosh”, which I believe (as does Nat Irons, who submitted this observation) was the last remaining high-profile usage of “Macintosh” by Apple. “Mac” is used all over the place — PowerMac, iMac, eMac, Mac OS X, .Mac — but the full “Macintosh” has apparently been placed on the same shelf as the six-color Apple logo.

Update: There are at least two remaining instances of “Macintosh”:

• The Finder’s about box still contains the slogan, “The Macintosh Desktop Experience”. (Thanks to Scott Lewis and Peter Orosz.)
• The default name for the startup disk on a new Mac is still “Macintosh HD”. (Thanks to Michael Croft.)

Mac OS X 10.0 replaced the Finder’s each-item-gets-its-own-info-window concept with the Info Inspector, a single window that applied to whatever was selected in the Finder. Rather than showing multiple items’ info side-by-side, it displayed a single list of shared attributes for multiple items. This change was despised by just about everyone who didn’t previously work for NeXT.

Classic-style Get Info windows returned to the Finder in 10.2, but, frustratingly, only if you invoked the Get Info command one item at a time. With multiple items selected, you still got a single “Multiple Item Info” window.

The Tiger Finder has finally gone back to the classic style: select multiple items, invoke Get Info, and you get a separate Get Info window for each item.

If you really want the single-window Info Inspector, it’s still available via Command-Option-I. Or, with Command-Control-I, you can get a version of the single-window summary info in a regular window (as opposed to the floating palette used by the Command-Option-I inspector).

Update: If you’ve got more than 10 items selected and do a Command-I, the Finder reverts to the old-style single info window. This is a nice touch — if you have that many items selected, it’s likely what you wanted. This is especially true if you’re accustomed to the previous behavior and are in the habit of selected a large group of files and using Get Info to see how large the entire group is.

(Thanks to Nick Matsakis for the original tip, and to Ken Sjoquist for noting the difference with more than 10 items selected.)

It was inevitable that this was going to happen eventually, and now seems like a good time. It’s well-nigh time for the world to acknowledge that Mac IE is dead.

(Thanks to James Duncan Davidson.)