OS X Lion brings dramatically redesigned versions of the classic iCal and Address Book applications. Many people, or at least some important decision makers inside Apple, are very happy with these changes. Other folks, such as myself, believe they look and behave like crap.

When I first saw the Lion version of iCal, my eyes were drawn to the obnoxious bits of paper that cling to the top of the window, artificially and pointlessly leaving the debris that you might find on a real-life calendar with removable paper sheets:

As Cathy Shive pointed out in her NSConference talk on user interface metaphors, the presence of junk like this in an application is at best useless, at worst distracting and detrimental to the usability of the application. I remember her saying in her talk, before Lion’s iCal had even been presented in a private developer beta, that little things like paper scraps in an application are particularly annoying because she always wants to try to pick them off just as she would with a physical object.

Lion has given me the opportunity to empathize deeply with that concern. I hate those cruddy paper bits, and I can’t pick them off! Or can’t I?

To clean up your copy of iCal on Lion:

1. Select the iCal application in the Finder and press cmd-D to duplicate (make a backup, for safe keeping).
2. Control click the application icon and select “Show Package Contents.”
3. Navigate to Contents/Resources/
4. Select “CanvasTopTile.png” and open it up in Acorn or another, less attractive image editor. Or download my edited version and replace the original file.
5. Select the paper bits and “clean them up” by deleting them.
6. Reopen iCal, and bask in the glow of your clean white calendar:

Granted, this only fixes the paper bits. You’re still stuck with that horrendous tan leather toolbar. But at least that doesn’t beg to be picked at. It’s worth noting that the tan leather can also be tweaked by editing a variety of other image resources in the bundle. It’s trickier because many of the graphical components of the toolbar are designed to blend with the leather background, so you’ll end up having to change quite a few of the images.

I’m reminded of another great observation Cathy made in her talk: when you make very stylistic choices like this for a user interface, you dramatically increase the variety of reasons that the customer can be repulsed by the design. What if I don’t like leather? What if I don’t like tan leather? What if I prefer a running stitch to an outline stitch? You can argue that matte grays and subdued color gradients may invite the same controversy, but there’s a reason they are so common in user interfaces: because they’re far less likely to distract from the form and function of the application itself.

Addendum: Updating the iCal code signature. Thanks to rentzsch and daagaak on Twitter for pointing out that editing the resource will break the “code signature” on the application, put there by Apple to assure users that the application 1. Was developed by Apple, and 2. Has not been modified by anybody but Apple. You can re-sign the application after tweaking it, to put it back into a  “signed” state, albeit not by Apple. Hopefully this will prevent it from prompting you all the time about approving connections to services like MobileMe. From the Terminal:

 codesign -f -s - /Applications/iCal.app

This reveals how little things like tweaking an application’s resources have wider-reaching consequences than they used to. I’m pretty sure you won’t miss any functionality in iCal by using a self-signed copy of the app vs. an Apple-signed version. But I could be wrong!

I’m pretty excited about most of the enhancements in OS X Lion, and in Safari 5.1, which was released along with it. But one of the most annoying changes in the version of Safari that ships with Lion is the removal of any keyboard shortcut for showing and hiding the active downloads list.

Downloads used to be shown in a completely separate window, which could be toggled using the keyboard shortcut Cmd-Opt-L. In Lion, they appear in a popover panel attached to the toolbar of whatever browser window you happen to be using. Unfortunately, there is no keyboard shortcut to toggle the appearance of this popover.

Using FastScripts and a simple UI Scripting script, I was able to restore this functionality, so that Safari on Lion toggles the panel using the familiar Cmd-Opt-L shortcut.

Download the “Toggle Downloads Popover” script

Download the script, and copy it to:

[Home] -> Library -> Scripts -> Applications -> Safari

Here it will show up in FastScripts (or Apple’s script menu) only when Safari is the front-most app. You can also assign it a keyboard shortcut, like Cmd-Opt-L, that will only be active when Safari is active.

Important: If your Mac is not configured to run with English as the primary language, the script will not work without a minor adjustment. You will need to open up the script and change the text string “Downloads” to the language-specific description for the downloads panel in your language. For example, to make it work with Safari running in Spanish, you would change the string to “Descargas”.

I find it very useful to be able to popup the panel when I am checking on the status of a long download, or when I want to check quickly whether I already downloaded something I had intended to. Hope this script works well for you as well!

Lion is the first operating system to require, and to fully take advantage of, 64-bit addressing modes in the Intel chips that power Apple’s Macintosh computers. One of the side-effects of this is that every object identifier in Mac OS X’s Cocoa programming framework (typically an address in memory), is now twice as long as it was in a 32-bit environment.

Apple has apparently taken advantage of the 64-bit runtime in Lion by optimizing the Objective C runtime itself to use some of these extra bits for, shall we say, clever purposes. Bavarious describes an optimization through which Apple is able to replace previously full-fledged opaque objects such as NSNumber with an object-placeholder that exists entirely as the 64-bit “object address” itself. This means that, for a wide range of “simple” objects, no additional memory allocation is required, and no retain/release memory management is required for the “object.”

The trick relies on a implementation detail of the system, that allocated blocks of memory will always be aligned at 16-byte offsets into the address space. This leaves a bunch of numbers that can be represented in 64-bits, that cannot reasonably be assigned to any other object. To understand this practically, imagine that your neighborhood’s postal addresses are all assigned at offsets of 10: 30, 40, 50, etc. A clever postal service could institute an addressing system that uses an “invalid” address such as “31,” to perhaps mean “deliver to 30 with expedited afternoon delivery.”

Cleverness like this with encoding extra information in memory addresses is a time-honored tradition. I recall the days of 24-bit addressing on classic Mac OS, where Apple, and many 3rd party developers, observed that the high 8 bits of a typical memory address could be tweaked and used to store additional information, because the system would never reference those bits when resolving a particular address.

In those days, using those extra bits turned out to be a pretty significant headache when 32-bit addressing ultimately came along, and lots of code had this “crufty” treatment of addresses to clean up. Perhaps it is a memory of situations like this that caused Jon “Wolf” Rentzsch to comment in his bookmarking of the above-referenced blog post:

“Every tagged pointer has its lowest bit set, hence tagged pointers are odd integers” Strikes me as a really bad idea. [Emphasis Mine]

But the difference now, in this scenario, is the “cute hacking” is all being done by a central power, with and in terms of opaque objects that only Apple has the authority to change. I think this is a really clever hack that will undoubtedly lead to some serious performance gains in Lion and beyond. It’s hard to imagine specific outcomes that will make Apple regret adopting this strategy. In the worst case scenario, an addressing system of future Macs will not leave any “spare” bits to be exploited, so the runtime will simply revert to its previous behavior.

One of my favorite new features in Lion is a completely revamped “FileVault”, Apple’s brand-name for encryption techonologies that protect the data on your disk from eavesdroppers, should the disk be lost or stolen.

In Mac OS X 10.6 and earlier, FileVault was a feature that only affected your home directory. In OS X Lion, it applies encryption at a very low-level, encrypting an entire volume of your disk at a time, and keeping it encrypted as you use it.

I was able to enable FileVault for my boot volume with relative ease, using the Security & Privacy preference pane in System Preferences. However, the UI for this is pretty limited, and notably, it only allows you to protect the computer’s startup disk.

The way I have my Mac configured, most of my sensitive data is not on the startup volume, but is instead on a second partition called “Data” where I keep my home directory, media files, etc.  Apple’s Disk Utility allows you to erase and reformat a volume as encrypted from scratch, but what if you want to migrate a volume in-place, the way the system does the boot volume? You’re not completely out of luck.

OS X Lion ships with a low-level technology called “core storage,” which is used to facilitate a wide variety of disk-maintenance functionality, including whole-disk encryption. To get a quick look at what core storage supports, type “diskutil cs” at the Terminal command line. For a more in-depth look, type “man diskutil” and search for the core storage command documentation.

Important: This is the part of the blog article where I warn you to be very careful before proceeding. The diskutil command is capable of doing incredibly destructive things to your disk and to your data, so you should feel confident before doing anything that you have a 100% reliable backup of your data.

To convert an arbitrary volume to Lion’s whole-disk encryption, you use diskutil’s core storage “convert” command, and provide a passphrase. For example, if you have a volume called “Data” attached to your Mac, you would run something like this from the command line:

% diskutil cs convert /Volumes/Data -passphrase '[yourPasswordHere]'

Warning: at least one person has run into an issue where the passphrase was set to something unexpected because of characters such as ! and $ being interpreted by the shell before being passed to the tool. One more good reason to make sure you have a backup before messing with any of this stuff.

The “diskutil cs convert” command kicks off a conversion process similar to what the System Preferences panel does when allowing you to convert your main startup volume to core storage with encryption. At any time during the conversion, you can use the diskutil command again to see status of your volumes, whether they are encrypted, not encrypted, or in-progress while converting.

% diskutil cs list

You’ll see a bunch of information, but search carefully for the named volume (e.g. “Data”) that you just started the conversion process on. You’ll find a line starting with something like:

Size (Converted):

This shows you what the progress in the conversion is. From time to time, check this manually, to see how far along things have progressed.

Caveats

In addition to the major admonition above to backup your data carefully, you should also know that after you have converted a volume, it seems to be in a sort of provisionally encrypted state where it’s still being treated by the running OS as a “native volume” although it’s been converted and is ready to be treated as a “core storage” volume. I have to confess I don’t really understand it 100%, but it seemed like a really good idea to me to restart as soon as possible after the conversion is complete.

But before you restart, bear in mind that there appears to be a bug in the login process that will prevent a user whose home directory is on an encrypted (“locked”) secondary volume from being able to log in. It seems that whatever logic Apple applies to unlock volumes at login time is not applied early enough to allow the actual login to occur. This means that if you converted your secondary volume like I did, and it contains your home directory, you won’t be able to login.

For this reason, make sure that you have a valid account to log in to whose home directory is located on the main startup volume. In my experience, the process of logging in to this main-volume account will prompt the system to ask for the secondary volume’s password in order to unlock it. Once the secondary volume is unlocked, you can log out and log back in to your regular account, with the home directory on the secondary volume.

This bug is pretty annoying. Hopefully this is something that Apple will get fixed soon, and it may be for bugs like this that they haven’t enabled full-disk encryption as a full-fledged user-facing feature of the operating system. In the mean time, if encrypting your data is important to you, I hope these instructions and caveats will serve you well.

Update: Not surprisingly, this topic is covered in some detail in John Siracusa’s Lion review.