Agentless Backup is Not a Myth

Mac Secrets When I kicked off Mac Secrets, the first thing I looked at was "a better way to build OS X preferences." In this installment, I'll be looking at various undocumented aspects of PreferencePanes.framework that happen to be a documented framework.

Moreover, the stuff I'm looking at has got nothing to do with preference panes! Confused? Let me explain.

Although this framework is documented, it contains a number of classes that most definitely aren't. Here, I'm going to concentrate on a class called NSPrefPaneUtils. As the name suggests, this contains a set of utility functions that are of general use to anyone writing a preference pane - or anyone else for that matter.

To make use of the class, just create an Xcode project and - in the usual way - drag the aforementioned framework from /System/Library/Frameworks into the Frameworks group of the new project. Most of the methods implemented by NSPrefPaneUtils are class methods, so you don't need to instantiate an object before using them. For example:

+ (BOOL) isMacOSXServer;
+ (BOOL) hasBattery;
+ (BOOL) isTimeMachineEnabled;

As is obvious from the names, these will tell you whether you're running OS X Server, whether your machine has a battery, (not whether or not it's currently on battery power, which is a different issue), and whether or not Time Machine is enabled.

Here's another useful method:

+ (void) enableControls: (BOOL) enable 
                 inView: (NSView *) view 
                   deep: (BOOL) deep;

Given a specific view, this method enumerates the view looking for any controls and enabling or disabling them as indicated by the "enable" parameter. If you set "deep" to "YES", any encountered NSView sub-views are recursively enumerated in the same way. This is a useful method if you want to - for example - programmatically disable or enable all the controls in a complex group box or even in an entire panel.

The real core of NSPrefPaneUtils, however, is devoted to the representation of key-codes and modifiers. If you've ever built an application that uses configurable hot keys, you'll know that getting this right can be quite tedious. There are some terrific open-source contributions around for recording key presses like Shortcut Recorder for example, but if you want to do something like simply display an existing key-code complete with modifiers, then even doing that can be a bit messy.

NSPrefPaneUtils contains a number of methods to make life much easier. For example, suppose you've used Shortcut Recorder to record the user's hot-key preference for a particular program action. This gives you a virtual key code and a modifier mask. To convert this back into a human readable form, you could do something like this:

NSLog ([NSPrefPaneUtils humanStringForVirtualKey: 96 modifiers:  NSCommandKeyMask]);

On my keyboard a virtual key-code of 96 corresponds to the F5 key. Hence, the output will be "Command F5". If you'd rather that the user saw "_F5", then use stringForVirtualKey:modifiers: instead. (I've included all the available selectors in the NSPrefPaneUtils.h file along with the demo program, at the end).

If you just wanted to display the modifier mask in human readable form, then stringForModifiers: (e.g. "_F5") or humanStringForModifiers: (e.g. "Command"). Likewise, _labelForVirtualKey: will give you a human-readable representation of the key-code on its own.

If, incidentally, you're wondering what startKeyboardMonitor and endKeyboardMonitor do, they're used internally within the framework - you should not call these methods yourself. They simply manage an internal IOKit notification mechanism, which keeps track of whether the currently attached keyboard or keyboards have an "Fn" key or not. In this way, the routines I've mentioned automatically take care of whether or not to add "Fn" at the front of a keystroke's description. That's the purpose of the internal _needFN method.

Test the PrefPaneUtils class

Anyway, back to our story. One especially interesting call is stringForSymbolicKey: if you're not familiar with symbolic keys, suffice to say that this is a mechanism that lets things like Dock, Exposé and Spaces to allocate numeric identifiers to hot-keys in a persistent, global manner. The real guts of this are undocumented (natch) and buried deep inside CoreGraphics, but it is possible to make use of symbolic keys in your own code. For now, just take a look at the call below:

NSLog ([NSPrefPaneUtils stringForSymbolicKey: 8]);

The number eight isn't a virtual key code, it's a unique number identifying a specific symbolic key. In this case, the keystroke that moves focus to and from the Dock. The default setting for this hotkey is Control-F3 and, as expected, the above statement will generate "^F3" as output on my machine. For a lengthy list of available symbolic keys, check the excellent work of Alacatia Labs' developer Joe Ranieri here.

Hopefully, this has whetted your appetite for those undocumented PreferencePanes.framework classes. Next time, I'll delve deeper into symbolic keys.

Ahead of that, you can get your hands dirty using full source code and demo project, which can be found here. One word of caution OS X fans: the demo won't appear to do anything - but just look at the console output.®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery