One of the UI concessions OS X Lion makes to a time-honored Microsoft Windows feature, is the addition window-resizing hotspots on all edges of a given window. Traditionally, Mac users have been limited to resizing windows only through the use of the “Zoom” button in the title bar, or by clicking and dragging the resize control at the bottom-right corner of a window.

Now you can grab any edge of a window and grow or shrink it to suit your wants. What I didn’t notice until today, however, are a few interesting variations on window resizing that are facilitated by pressing a modifier key while resizing.

Hold the option key while resizing to cause changes in the  window’s width or height to be made in equal measure on each side of the window. For example, clicking and dragging the right edge of a window with option depressed will cause the left side to grow or shrink in mirrored fashion. For lack of a better term, I’ll call this balanced resizing.

Hold the shift key while resizing to impose constrained resizing. Whatever direction you grow or shrink the window, adjustments will be made so that the ratio of height to width remains the same.

These are some pretty geeky resizing modes. I don’t foresee using them particuarly often, but it’s interesting to know they are there.

(I did some preliminary Googling before sharing this, and didn’t see any documentation come up. I’ve since noticed that Matt Gemmell already shared this tip in a Twitter update.)

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