Skip to content
Thoughtful, detailed coverage of everything Apple for 34 years
and the TidBITS Content Network for Apple professionals

Introducing Dashboard

Think of Tiger’s new Dashboard feature as a constantly running pseudo-application. It is constantly running in the sense that you cannot quit it; it is a pseudo-application in the sense that it isn’t a distinct process (it’s really an aspect of the Dock) and in the sense that (like the Dock) it behaves differently from any other application.

Dashboard is always in one of two states. When it isn’t the frontmost application, it is invisible and inert. When it is the frontmost application – you can summon it either by pressing a user-configurable keyboard shortcut (F12 by default) or by clicking its Dock icon – it takes over the entire screen, covering all windows, the Desktop, and the menu bar with a dark haze, rather like London in a Sherlock Holmes episode. Gleaming in front of this haze are some roughly rectangular areas of bright color: these are the Widgets to which Dashboard plays host. All you can do when Dashboard is frontmost is interact with a Widget – look at one, drag one around, click one. All the while, your other applications remain active in the background. When you’re done using Dashboard, you click somewhere in the haze, and it and all the Widgets vanish, and you can proceed to use your computer in the normal way.

A Widget is itself a sort of pseudo-application. It’s effectively just a window, and a non-standard window at that: it has no title bar, no Aqua-style interface, and no menus. In fact, there are essentially no standard rules of interface for a Widget; it is effectively painted on the screen in any style and shape the developer fancies. Behind the scenes, a Widget is more like a piece of a Web page than anything else; it is implemented not with Carbon or Cocoa but with HTML, CSS, and JavaScript. A Widget file is a bundle; a dozen or so Widgets are installed by default, in the /Library/Widgets folder, and you can actually open a Widget bundle in the Finder (using the Show Package Contents contextual menu command) and read its "code." Third-party Widgets, which are already becoming available from various Web sites, can be installed here or in your user’s ~/Library/Widgets folder.



Your installed Widgets constitute a smorgasbord from which to choose; which ones actually appear when you summon Dashboard is up to you. You click a big "+" at the lower left of the screen to reveal the Widget Bar; it displays icons for all your installed Widgets, and you click or drag an icon to instantiate it in the Dashboard main area. Similarly, when the Widget Bar is showing, Widgets in the main area have an "x" that you can click to dismiss them (and when the Widget Bar is not visible, you can reveal a Widget’s "x" by holding the Option key and hovering the mouse pointer over that Widget). It is legal and useful to instantiate a particular Widget more than once. For example, the Clock widget shows a clock set to a specific time zone, so to show the time in, say, both Los Angeles and Indianapolis, you instantiate the Clock widget twice, and set one instance to Pacific Time and the other instance to, uh, whatever weird time zone they think they’re in in Indianapolis.

The Dashboard architecture – where either Dashboard is absent and you can’t work in it at all, or else it is frontmost and you can’t work anywhere else – may seem rather restrictive, especially in comparison to Konfabulator, which permits its Widgets to be interleaved with ordinary application windows. However, it all makes more sense if you think of a Dashboard Widget as something you glance at, or work with for a just a moment, and then dismiss. If you always need to see a clock, use the System Preferences (Date & Time) clock. If you need to glance at a clock now and then and then get back to work, use the Dashboard clock. From this perspective, users may well be pleased that when Dashboard is not frontmost, its widgets occupy no screen real estate (like a window), no Dock slot (like an application), no menu bar space (like a status menu), and no CPU time. On the other hand, the single-layer architecture decidedly favors user with big monitors; my 12-inch iBook feels crowded when just half a dozen Widgets are present.


The decision to base Widgets in HTML and JavaScript is more controversial. From a user point of view, I find the lack of uniform interface decidedly off-putting. When I see an Aqua window, I know at a glance what its parts and components are for, but every Widget is different; you don’t know what regions are clickable (button-like) or draggable (title bar-like) until you try it. And they’re funny-looking; they don’t look like one another or like anything else we’re accustomed to in Mac OS X. From a programmer’s point of view, reactions will vary. If you’re already a JavaScript maven, you may be delighted. But compared to the elegance and convenience of Cocoa, the HTML and JavaScript approach to programming strikes me as messy; my own MemoryStick application would make a good Widget, but having studied the Dashboard programmer documentation, the chances that I’d ever do the massive rewriting involved are vanishingly small. The way to know whether Dashboard is really a useful and productive part of Tiger is to wait and see, as Tiger matures, what kind of Widgets get written and whether users really use them.


< macosx/13636>

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 33 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

This site is protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.