The
preference system of Mac OS XThe
preference system of Mac OS XMac OS X uses sophisticated technology to handle preference settings for all applications natively developed for this operating system. The programs don't need to care about reading or saving their preference settings to files. This is completely handled by Mac OS X in an automatic and transparent way. Applications even don't even “know” how or where their settings are being stored.
When an application likes to define a preference setting for a user, e.g. the default position on screen where the user has placed the main window of a certain application, it just sends a request to Mac OS X “I am application A. Store the value B of the setting named C for the user D”. The operating system automatically ensures that it will remember this setting later when application A (run by user D) should ask for it, no matter if the application or the computer had been shut down in the meantime and had been restarted later.
So when the application likes to position its main window to the very same location the window has been the last time the user had used that window, the application will ask Mac OS X “I am application A. Give me the preferred value for the setting named C for user D”. Mac OS X will then return the previously stored value (B) to application and the application can use it to position the window. That way, the application has basically “remembered” the settings preferred by the user, but it doesn't need to know how Mac OS X did this trick.
Every application running on the graphical user interface of Mac OS X must have a unique identification. The preferences subsystem uses this identification to remember “this list of settings belongs to the application with that identification”. According to Apple's software design guidelines, the identification names must be built based on a hierarchical list of descriptive names, written from left to right in top-down order, separated by dots. The first part of the hierarchy must be the Internet domain name (DNS name) of the application's vendor, so two different software companies can never create the same identification for a program, even if their products should happen to have identical names.
Example: The unique identifier for Apple's web browser Safari is com.apple.Safari, because it is published by the company with the Internet domain name apple.com and Safari is the descriptive name to identify this program in Apple's software portfolio. Note how com.apple.Safari is written in top-down order, with the most important part at the beginning, while Internet domain names like www.apple.com are written in reverse order, with the most significant part at the end.
When working with the preferences subsystem, the application identification becomes the name of the subset of preference settings for this application and is called preferences domain name, or just domain name in that context. Depending on the type of file system where Mac OS X internally stores parts of the preferences database, the names may or may not be handled in a case-sensitive way. For this reason, preference domain names should always be seen as being case-sensitive, so com.apple.Finder and com.apple.finder represent two different preference domains.
Software companies are free to use more than one descriptive name components to identify a particular application or aspect of an application. Examples for this are com.apple.airport.airportutility and com.apple.airport.clientmonitor to identify two different applications which are both part of the subject area “Airport”.
Mac OS X uses a special domain to identify settings which should apply to all applications started by the same user. For example, the user default for the preferred page size for print outputs should have the same value for all applications. A user can define different page layouts in different applications if she explicitly chooses to do so, but there should be one single default being applied to all applications before the user has made such a distinction. This domain is called the Global Domain. PrefEdit uses this name whenever referring to preference settings applicable to all applications. Mac OS X may also use the reserved domain names NSGlobalDomain or kCFPreferencesAnyApplication internally.
For some particular cases, it is useful to have some kind of pre-registered domain, a list of settings which takes effect even if the user has not decided on a preferred choice yet. Those settings act as fallback values which are taken as a last resort if no other preferred settings could be found. This is especially important on a freshly installed operating system, or for a newly installed application where no default values are set the first time the user is launching it. For this special purpose, Mac OS X knows the concept of a registration domain which is built directly into the operating system, or application respectively. It behaves like a normal preferences domain, but is read-only and is actually not a real part of the preferences database. PrefEdit will use the term built-in domain to refer to it. Mac OS X uses the reserved name NSRegistrationDomain internally.
So far, we have mainly focused on the aspect “to which application does a certain preference setting belong”. But there are other kinds of areas or territories where preferences apply or should not apply. Each user of a computer should have the choice to use his or her own preferred settings. If user A likes to have a red desktop background, he should be able to set it, completely independent of user B who prefers a blue background when working with Mac OS X. This means the preference system also has to know the concept of per-user preference domains.
In professional networks, this should become more complex: If user A is a university student who works on a large campus network, his preference for a red desktop background should become active automatically for each and every Mac OS X computer in the network. So no matter if user A logs into a Mac in building P, or uses a different Mac in a lab of building Q, his preference settings and user profile should automatically “roam” with him. Mac OS X will automatically take care of that, too, if the network is configured to use central home folders for all users. Other settings however, e.g. the preferred output quality for a certain printer, should be computer-specific. Maybe one computer has a black-and-white printer, while another system uses a color printer with very different printing settings. These particular settings should not move between computers, although Mac OS X should still remember them.
This means there are in fact three different aspects of preference domains:
Whenever Mac OS X stores or retrieves a preference setting with a given name, it will always take into account to which domain intersection of application, user, and computer area a certain setting applies. This decision is based on the current user session. There can be eight different combinations of aspects as shown in the following picture.
Three different domain concepts can be combined into eight
intersections.
The gray areas are currently not implemented in Mac OS X.
Typically, Mac OS X will assume the domain intersection “specific application - current user - all computers” when setting a preference value and nothing else has been specified.
The pair “all users - all computers” would require a central network repository where Mac OS X could store preference settings for all roaming users and all computers in a network. Although Mac OS X is basically prepared to do so, Apple has currently not implemented this combination. This means the domain intersections
won't be used in Mac OS X versions published so far. This may change in future releases of the operating system.
When an application is asking Mac OS X to retrieve a certain preference setting, the current user session is taken as basis for the decision which setting in which domain intersection takes effect. If a particular setting is available in multiple domain intersections, settings with higher priority should override settings with lower priority.
For example, if a user has defined her individual preference for print output quality in a certain program running on a certain computer, this setting should take precedence over the more general areas. It should automatically override a setting with the same name if it has also be defined for all computers and/or all users. Mac OS X uses priorities based on the following list to decide which preference settings takes effect:
This list is taken as a search path for preference settings, traversed in top-down order. The first entry in the list for which the setting in question is defined will “win” and take effect. So this entry will override all entries of the same name which may come later in the list.
PrefEdit can visualize this complex search path when desired. You don't need to learn the priority list, PrefEdit will display exactly which preference settings in the domain intersections override the settings of intersections with lower priority.
We have learned that a preference domain contains a list of named preference settings. But what exactly does the term “setting” mean in this context? A preference setting in Mac OS X is defined by three components:
Each setting must be contain a value of one of the follwing data types:
Note that it is allowed to nest dictionaries and arrays in any order and unlimited depths. A setting could contain an array of arrays of dictionaries of strings, for example, or a dictionary of arrays of numbers. Arrays and dictionaries are also allowed to contain items of different types, for example an array with a number at index 0, a string at position 1 and a Boolean at position 2.
It is completely up to the different applications to interpret the property keys, types and values of the settings. Neither Mac OS X nor PrefEdit can know how an application is using a given setting. In selected cases however, the vendor of an application may have given additional hints via a preference manifest.