Configuration of Kontact is done by extending the modular mechanisms used in the desktop-wide KDE control center to the application level. Configuration dialogs are composed of modules which are dynamically loaded at run-time. A generic configuration dialog provides access to all modules relevant for the applications embedded into Kontact.
The selection of the components which are present in Kontact is done by an extension of the metadata associated with all programs. The generic KDE plugin selection infrastructure makes use of this data by providing a backend for accessing activation state of plugins and a GUI for the user selecting which plugins should be active.
General access to the actual configuration options is performed through the KDE configuration backend (KConfig XT, see section 4.4.2). It provides an abstract description of configuration options which is reused in the GUI, a generated API to the configuration data which is used to access and share configuration data in a well-defined way, and other things, like the desktop lockdown features of the KIOSK mode.
The configuration dialog is one example where application integration in Kontact is more than just merging views in a common main window. The configuration dialog provides access to all options of the components selected to be embedded into Kontact. It creates a common hierarchical view of all available configuration pages. See figure 4 for a screenshot of the integrated configuration dialog.
Technically the different pages of the configuration dialog are implemented as dynamically loaded modules using the same programming interfaces as the desktop-wide KDE control center. Each module has an associated file which contains meta and control information like the name of the module including translations, the name of the library to load or the type of control module, i.e. in which dialog and where in the hierarchy it is to be shown. This file uses the Desktop Entry Standard [35]. This mechanism allows the construction of the navigation part of the dialog without actually loading the modules. The fact that the modules are implemented as independent modules allows them to be loaded on demand as they are needed by the user interface, even without requiring to have the KPart of the associated application to be loaded in memory.
For storage of configuration data the standard KDE configuration backend is used. It stores the data as grouped key-value pairs in simple files using an INI-style syntax. The configuration backend supports cascading configuration files, thanks to which users settings are read and merged from several files, starting from global system-wide files down to user-specific files in the users home directory. In general information from more specific files takes precedence over information from more global files, but this can be modified in the KIOSK mode.
KConfig XT (XT stands for "extended technology") is an additional level of abstraction on top of the standard configuration backend. it is based on an abstract description of the configuration using XML. See figure 5 for an example file. The description contains information on the names and types of configuration entries, the text used for labeling and explaining the options, default values and a logical grouping of the entries. It also contains some control information like where the configuration is stored.
To provide applications with convenient and type-safe access to the configuration data KConfig XT includes a tool for generating the C++ code, required to access the data, from the XML descriptions files: the "kconfig compiler". The generated code provides direct access to the configuration entries by creating individual functions for each entry. These can be used within the application code when access to specific entries is needed. There are various options to control the generation of the code, so that it can be adapted to the specific needs of applications. See figure 6 for an example of generated code.
The generated classes also provide a generic way to access the configuration entries. This is used for widely used actions like reading and writing of the configuration data. The generated class is also used for connecting configuration dialogs to the backend in a generic way. There is a special class KConfigDialog which associates the widgets of a configuration with configuration entries based on the names of the entries and the widgets. This makes it very easy to create configuration dialogs because all handling of the actual data is done automatically in the backend and the developer only has to create an XML description of the configuration options and a corresponding dialog. If this is done with GUI design tools like Qt Designer [30] creating configuration dialogs can be done without having to write more than a few lines of code.
There are some additional tools under development which make use of the generic nature of the KConfig XT framework. One is an application-independent editor for configuration options which works on the configuration files via KConfig XT. This allows to manipulate options which have no representation in the GUI, to edit remote configuration files or to edit the configuration of multiple applications in one go. The other tool under development is a graphical editor for the KConfig XT XML descriptions. This makes it possible to create and edit configuration without having to know about the XML format. Together with Qt designer this makes a powerful suite of tools for easy implementation of the configuration parts of applications.
The advantages of the KConfig XT approach are that there is only a single location where configuration keys and default values are specified, that there is type-safe access to the data for applications, that details of reading and writing the configuration, e.g. applying default values, are automatically handled and that there is a way to access the configuration in an abstract way, which is in particular useful for generic tools not tied to a specific set of configuration data, for example a generic configuration dialog.
Kontact which, by its nature of application integration framework, combines a lot of configuration options greatly benefits from the simplifications which are made possible by the use of KConfig XT.
To fine-tune the configurability of applications and to give administrators a tool to control how users configure their applications KDE provides the so-called KIOSK mode. This is an extension of the standard configuration backend which allows to control how configuration options can be changed. This offers all the tools required for features like desktop-lockdown.
The key concept of the KIOSK mode are immutable options. Any entry of a configuration file can be made immutable by adding a special flag to its key. This means that the configuration backend won't write any changes of this entry anymore. As configuration files are read in a cascaded way an administrator can add the flag making an entry immutable in a global configuration file which the user doesn't have permissions to write. This way the option can't be changed by the user anymore.
With the integration of different applications in a common framework, as happens in Kontact, the need for common configuration increases. There are several configuration options which are the same for different applications, like name and email address of the user, depend on each other or can be deduced from other options, like server names, addresses of certain files or services on the same server.
One example is the configuration for access to a groupware server where data like addresses of incoming and outgoing mail server or for accessing contact or calendar data can be created from knowing which kind of server is to be used together with address and login information for a specific server.
Configuring this information in all the different applications is cumbersome, although the fine-grained configuration is needed for tuning the applications to special needs and to be able to handle different usage scenarios. The classical solution to this problem is to provide configuration wizards which collect the required information for configuration at a centralized location.
In Kontact this problem is addressed by a special kind of application-spanning configuration wizard based on an extension of KConfig XT for propagation of configuration options. The information which is needed to deduce the detailed configuration for the individual applications is described by a standard KConfig XT XML file and the corresponding GUI is created on top of this. For propagation of the information to the configuration of the individual applications a set of rules is added to the KConfig XT XML file. These rules can specify simple copying of data to other configuration files or more complex conditional propagation based on other data, e.g. based on the information if a special feature is enabled or not. it is also possible to define custom rules which are accompanied by C++ code. This gives the flexibility to also handle very complex cases.
The wizard dialog reads and interprets the data and rules from the description files, integrates the GUI for setting the options and applies the data put in by the user according to the defined rules to the configuration of the involved applications. This mechanism makes it very easy to set up configuration wizards as the application developer can use the generic mechanisms and only needs to write code for handling of special cases. It has the additional advantage that it creates a formal specification of how the configuration is affected by the wizard which can for example be exploited in the GUI to indicate how the different configuration options depend on each other without requiring any special handling by the application developer.
Kontact provides wizards for configuring access for groupware servers like Kolab [31] or eGroupware [32]. It would also be possible to use the wizard infrastructure for setting up user profiles or to make it possible to apply policies to the configuration. It might also be useful for storing and reapplying certain configurations of individual users, e.g. when moving between different systems.
