About | Buy Stuff | Industry Watch | Learning Curve | Products | Search | Twitter
Home » Learning Curve

Defaults

Windows users would love to have it so good.

The NeXTSTEP/Cocoa defaults system may seem bewildering or even hostile at first, but when you get to know it it's bloody beautiful.

And to appreciate just how good this system is, one has to first make a comparison with that paragon of programming excellence, Microsoft Windows.


Windows - both 9x and NTx - use the 'Registry' to store settings data. The Registry is a veritable jungle of binary gobbledegook that can only be read with a special 'Registry editor' - which Microsoft themselves advise people to not use.

The Windows Registry is divided into two major areas known as keys:

HKEY_LOCAL_MACHINE (HKLM)
HKEY_USERS (HKU)

Windows aficionados might contend there are more keys, but they would be wrong: all the other keys displayed in Registry editors are 'aliases' to somewhere within the two keys listed above.

The 'division of labour' here is significant: Windows divides settings into what is particular for this computer (HKLM) and what is particular for this user (an alias into HKU). Unfortunately, the division does not work:

File associations are found not for users but for the computer as a whole.

The infamous HKEY_CLASSES_ROOT is located under HKLM, meaning the machine can only accept one application to open any one file type.

If Sally has an MS Office licence and wants to use Word to view and edit RTF files, that's fine; but if she shares her machine with Sue, who does not have an MS Office licence and prefers WordPad anyway, they're screwed.

They'll have to continually jiggle the Registry back and forth and may even part as enemies one bleak day.

Windows is truly a 'standalone' machine and here that quality shines clearly through.


OS X is a Unix system: it's multi-user from the get-go. The defaults system inherited from NeXTSTEP is at once malleable and flexible. Defaults are found in different so-called domains, where successive domains override settings found in previous domains.

One can have general settings for an entire computer which a particular user wants to override: no problem.

You can find any number of 'Preferences' directories on your hard drives, and these bespeak the defaults system in operation.

  1. You can have access to a Preferences directory through a network connection.

  2. You have a Preferences directory in /Library.

  3. You have your own personal (and private) Preferences directory in ~/Library.

  4. You can override any setting anywhere on the command line.

Try this little trick (from a Terminal window):

/Applications/Safari.app/Contents/MacOS/Safari -IncludeDebugMenu 1

(If you start Safari again the 'normal' way and you've not previously enabled the Debug menu, it shouldn't appear.)

In the above list, 2 supersedes 1, 3 supersedes 2, and 4 supersedes 3.

You'll find a file called 'com.apple.LaunchServices.plist' in your own Preferences directory: this is an enumeration of your personal file associations. Someone else might open HTML files with Camino; you've decided to use Safari (on the same machine); when you double-click an HTML file, Safari will open it, and the others running Camino will not be affected.

The layout of your LaunchServices file is eminently straightforward. You can look at it with the ADC property list editor or with any text editor (which is often easier). Everything is organised under the 'LSPrefsBindings' key.

The keys under LSPrefsBindings are for the file extensions in use. A single letter prefacing the extension and separated from it with a colon gives a hint as to what type of extension is being discussed. (If it's a 'U' then it pertains to the 'scheme' and not the extension.)

So it's eminently easy to override system defaults and establish settings of your own - and not just application-specific settings, but system-wide settings for file associations and the like.

Something which will always be impossible under glorious Windows (which can't handle last minute command line changes either).


And the defaults system is working all the time, behind the curtains, to serve you better.

Developers need often do no more than submit that various controls in their application windows should save pertinent settings and it becomes a fait accompli with no further code written - the defaults system takes care of the rest.

System-wide files govern things like extension of your Save As dialog, its placement on screen, your most recent directories, and so forth.

And all this benefits each and every application you run, has no bearing whatsoever on what anyone else runs, and it's all automatic.

Windows users would love to have it so good.

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.