Leopard’s resolution (in)dependence

by

I’ve noticed that a lot of people on the various Mac forums are interested to know what happened to resolution independence (RI) in Leopard.

Well, having poked around a little today, I can say that support for RI is considerably better than it was in Tiger. In fact, here’s a screenshot of QuickTime Player running at 216 dpi:
quicktimeresind.png
(click for full size version)

The Dock also works very well, proudly showing off the new 512 x 512 icons:
dockresind.png
(click for full size version)

So it’s looking pretty good so far. However, the experience of resolution switching is, by all accounts, not very Apple-like. At the moment, the screen resolution is changed using the Quartz Debug application included in the Developer Tools:
qd.png
This looks fairly user friendly: drag the slider to change the screen resolution. However, on dragging the slider all that happens is a Dock restart; running applications are unaffected by the change and have to be quit and restarted in order to honour the new settings.

Once apps are restarted, system-supplied widgets seem to look pretty good on the whole: check boxes, buttons, sliders, radio buttons, text fields, segmented controls, tabs and lists all look extremely sharp. The most prominent graphical glitch in the standard Cocoa controls is with drop down menus, which have a slight drawing problem as shown here (at 144 dpi):
menu-drawing-glitch.png
(click for full size version)

So there’s clearly been substantial progress in this area since Tiger, but the (rather large) remaining problem is the extensive reliance on bitmap images for custom controls. Looking in the resources folder for Photo Booth, for example, reveals over 100 bitmaps which obviously will not scale well to higher resolutions.

To gauge the extent of bitmap-based controls beyond Photo Booth, I’ve had a look in a fair few application packages today and I’d say there’s still a huge amount of “vectorisation” left to do before Apple would consider going prime time with RI. So much so, in fact, that I’d say we won’t see it exposed in System Preferences until Mac OS X 10.7 Feral Alley Cat.

Quartz Composer goodness

by

Delving into Leopard’s /Developer folder shows that Apple has spent a lot of time writing sample apps for developers to play around with to get to grips with the massive number of additions. In particular, a lot of work has clearly gone into Quartz Composer, whose headline feature is support for custom patches, including those written in GLSL.

Here’s some examples of some of the sample compositions that make use of the iSight camera:
qc1.png
qc2.png
qc3.png
qc4.png

I think the last one, called “Security”, was included as a screensaver in some of the earlier development builds. There’s a surprising amount to be found in the developer tools!

On the subject of Quartz Composer, Leopard now includes a large number of “default” compositions in /System/Library/Compositions/. I’m not sure what these are for, but they seem to encompass a lot of image units embodied in QC compositions. The new iTunes visualisers are also in there, along with all 40 Mb of Photo Booth movies. I was a little surprised by that, as obviously it means you can’t free up that 40 Mb of space by just deleting PhotoBooth.

(Incidentally, I notice that Leopard now includes the window’s drop shadow in screenshots taken using Cmd-Shift-4 space. Nifty.)

Leopard AppKit additions

by

Leopard just arrived this morning (TNT messed up yesterday) and thus far I’m loving it. Time Machine is in the process of performing its initial backup, so I’ll reserve judgement on speed until later, but the UI feels extremely responsive even with the backup going on.

Anyway, to the point of this post. I’ve briefly looked over the new developer documentation and have uncovered the following gems:

NSGradient
Looks like CTGradient won’t be necessary anymore, as Apple has added an NSGradient class to AppKit. This move is extremely welcome if long overdue — creating gradients previously involved a whole mess of core graphics shading calls (or using CTGradient).

NSCollectionView
Renamed from NSGridView in the developer seeds, NSCollectionView has apparently “been added to facilitate interesting animations”. I would have said it’s been added to display a collection of objects, but motives aside, this is really great AppKit addition, allowing for straightforward creation of iPhoto-style grids of basically anything you want. Each item in the grid is (unsurprisingly) an NSCollectionViewItem, created from a prototype view containing anything that knows how to draw itself, for example, an NSImageView and an NSTextField combined together in an NSBox.

NSRuleEditor and NSPredicatedEditor
NSPredicateEditor is a pre-built “criteria-builder” for things like smart folders:
predicate_editor.png
This ties into bindings and looks massively powerful.

HUD style windows
The head-up display style windows as found in iLife, iWork and now QuickLook are now a standard option of NSPanel, exposed in Interface Builder.

NSPathControl
Awesome. A standard control for showing file paths, probably powering the Finder’s “bread-crumb trail”:
path_control.png

NSToolbar enhancements
NSToolbars can now be edited directly in InterfaceBuilder!

NSSplitView enhancements
Loads of (overdue) improvements to NSSplitView, including divider-position-and-subview-collapse-autosave, the addition of -setDividerStyle: (for thick or thin dividers), programmatic subview collapse, easier double-click-view-collapse support, the ability to hide the divider when a subview is completely collapsed and a beautiful host of bug fixes.

Accessory views in NSAlert
NSAlert now supports the straightforward addition of a suppression checkbox (i.e. a “Do not show me this message again” option) and a -setAccessoryView: method for, surprisingly, adding an accessory view.

NSDockTile
-setBadgeLabel: and -setContentView: support for NSApplication AND NSWindow (for either the app or minimised windows)!

There is just so much new stuff, I can’t wait to get properly stuck in!