The configuration app is responsible for presenting and storing user settings/preferences. It registers a new main navigation item "Settings" as well as an interface for other apps to register preference options the user can adjust for the according app.
== Interface for other apps ==
The way apps can "register" their configuration options and settings the user can adjust to the configuration app is yet to be fully defined. The configurations app could "collect" the options each app wants to be listed in the Settings section through a Pub-Sub event (e.g. `configuration:preferences`).
NOTE: @Adityab, maybe you have an idea how Ember could otherwise facilitate this.
For apps to retrieve the settings managed by the configuration app, the latter registers an Ember service `config` which provides methods to `get` and `set` configuration options. Option names shall be prefixed with the module name followed by a colon (e.g. `mail:list:sorting`)
```lang=js
Ember.Controller.extend(
config: Ember.inject.service()
...
let sorting = config.get('mail:list:sorting', 'date desc');
...
```
NOTE: **TODO** define the exact API of the config service.
== Structure of the Settings UI ==
The "Preferences" panel organizes the various configuration options in a hierarchical way:
- Sections
- Blocks
- Settings
- Name
- Type
- Label
- Options
For each level, the configuration app could trigger a pub-sub event collecting the necessary information to render the according UI component. Like `configuration:sections`, `configuration:blocks` (with argument 'section') and `configuration:preferences` (with arguments 'section', 'block'). See [[http://trac.roundcube.net/wiki/Plugin_Hooks#Tasksettings | plugin hooks from Roundcube One]] 'preferences_sections_list' and 'preferences_list'.
=== Sections ===
A top-level list of general topics the preferences panel is divided into (e.g. General, Mail, Calendar, Tasks)
=== Blocks ===
Grouping of preferences inside a section. Can be understood as fieldsets with a title.
=== Settings ===
The actual configuration property to be rendered as a form element. Identified by the `name`, corresponding to the unique config option name the value is stored under. Additional properties like `label`, `type` and `options` advise the configuration app how to render the form element.
NOTE: **TODO** define the exact struct for such a settings item.
The visual display of the different components of the preferences panel is subject for UX design. Here are some examples showing possible approaches:
{F114110} {F114108}
Considering "Settings" to be the main navigation item, the user preferences (managed by the configurations app) is only one item on that panel. Other apps my register their own setting screens (e.g. folder manager, filter editor, etc.) which are not subject to the configurations app.