xbmc/xbmc — pull request #3453 by Montellese (2013-10-18 09:27:38+00:00)
Title: settings: custom setting controls

This implements one of the things that were on the "future work" slide of my settings system presentation: custom setting controls. This moves all the logic for setting control definitions, i.e. the tag in the settings XML definition describing how to present the setting in a GUI, out of the settings library and into the settings integration code (i.e. xbmc-specific code). Every new control is implemented in a class deriving from ISettingControl and has a unique "type". CSettingsManager has a new method RegisterSettingControl() which takes a type string and an implementation of ISettingControlCreator (which is implemented by CSettings and works the same as ISettingCreator).

This refactor will allow us in the future to easily add new control types without having to touch any of the code in the settings library. We "lose" a bit of sanity checks (i.e. a "edit" control probably doesn't make much sense for a boolean setting) but IMO we shouldn't put any limitation on combinations of setting types and setting controls.

There is one thing I'm unhappy with: In the definition of a setting with predefined options or a range of values we use
```
1

```
to define both the value and the GUI label of the option. IMO that label doesn't really belong there as it is only useful for GUI representation of the setting option. The same problem applies to
```
0
```
For the latter I have added a new tag to the spinnder control type but it's not really ideal either. And duplicating the whole
list just to be able to define the labels in the tag doesn't sound right either. We should either go with one ("label" attribute polluting the setting definition) or the other (moving all label definitions into but basically duplicating some information) and not the way it is in the PR right now. I only did that to be able to better show the problem.