4.1: Settings Architecture

Setting supports an object-oriented approach to preference definition and manipulation. What we want to express by this sentence is that:

1. each package or subsystem should define its own customization points (often represented as a variable or a class variable). The code of a subsystem then freely accesses such a customization value and uses it to change its behaviour to reflect the preference.
2. a subsystem describes its preferences so that the end-user can manipulate them. However, at not point in time, will the code of a subsystem explicitly refer to setting objects to adapt its behaviour.

The control flow of a subsystem does not involve Settings. This is the major point of difference between Settings and the preference system available in Pharo1.0.

Vocabulary

A preference is a particular value which is managed as a variable value. Basically such a preference value is stored in a class variable or in an instance variable of a singleton and is directly managed through the use of simple accessors. Pharo contains numerous preferences such as the user interface theme, the desktop background color or a boolean flag to allow or prohibit the use of sound. We will show how we can define a preference in Section 5.3.

A setting is a declaration (description) of a preference value. To be viewed and updated through the setting browser, a preference value must be described by a setting. Such a setting is built by a particular method tagged with a specific pragma. This specific pragma serves as a classification tag which is used to automatically identify the method as a setting (see Figure \(\PageIndex{1}\)). Section 5.3 explains how to declare a setting.

Pharo users need to browse existing preferences and eventually change their value through a dedicated user interface. This is the major role of the Settings Browser presented in Section 5.2.

Figure \(\PageIndex{1}\): A package declares and uses customization points as variables. As an example, UsedStrategy is declared as a class variable of RealEstateAgent. Such customization points are described with Setting instances that are created by the automatic running of setting declaration methods. The Settings Browser collects the setting instances and presents them to the user.

Figure \(\PageIndex{1}\) shows important points of the architecture put in place by Settings: The Settings package can be unloaded and a package defining preferences does not depend on the Settings package. This architecture is supported by the following points:

Customization points. Each application customization points should be defined. In Figure \(\PageIndex{1}\), the class RealStateAgent of the package UI-Basic defines the class variable UsedStrategy which defines where the windows appear. The flow of the package UI-Basic is modular and self-contained: the class RealStateAgent does not depend on the settings framework. The class RealStateAgent has been designed to be parametrized.

Description of customization point. The Settings framework supports the description of the setting UsedStrategy. In Figure \(\PageIndex{1}\), the package UI-Basic Setting defines a method (it could be an extension to the class RealStateAgent or another class. The important point is that the method declaring the setting does not refer directly to Setting classes but describes the setting using a builder. This way the description could even be present in the UI-Basic package without introducing a reference.

Collecting setting for user presentation. The Settings package defines tools to manage settings such as a Settings Browser that the user opens to change her/his preferences. The Settings Browser collects settings and uses their description to change the value of preferences. The control flow of the program and the dependencies are always from the package Settings to the package that has preferences and not the inverse.