xbmc/xbmc — pull request #2660 by Montellese (2013-04-27 15:58:16+00:00)
Title: Settings refactor

Here it is. The final "piece" of my settings refactor.

First off I tested this on windows and linux and compile-tested it on android. Any other platform is completely untested and is most likely broken due to the massive amount of (sometimes search & replace) changes in this PR. There are also a lot of settings which I wasn't able to test because they aren't available on my testing platforms.

I'll try to give a "quick" overview over how the new settings system works.
* The new settings system consists of XML files that contain descriptions of every setting (but not their value). These descriptions include an ID, label, help info, default value, access level, constraints, dependencies, GUI control definitions etc. There must always be a "settings.xml" file which is loaded first and then there can be other XML files which modify/extend the definitions from settings.xml. It's even possible to add completely new settings in those files and place them at specific locations in the GUI settings window. This PR contains additional XML files for every platform and any appliance can add additional stuff into "appliance.xml". Obviously it's possible to add additional XML files like these but that will require to change the code to also load that file. I'm sure there's room for improvement in this area but it already makes it a lot easier to specify platform-specific differences.
* After having initialized the settings system with the proper settings definitions it is possible to load multiple XML files containing the settings' values (e.g. guisettings.xml and advancedsettings.xml). Once all these XML files have been loaded, the settings system is ready to be used.
* From here on every change to a setting will trigger callbacks defined in ISettingCallback. Any class can implement that interface and register (on a per-setting level) to be informed about any changes. This allows to define any action that needs to be performed when a setting changes in a class which has the knowledge to do that (and not in CGUIWindowSettingsCategory). In the OnSettingChanging() callback it is possible to revert changing the setting of a value (e.g. if starting the webserver failed). With these callbacks it is finally possible to change settings from anywhere (not just the GUI) and it always has the same effect. You can even look at a list of settings in the GUI and execute some other code that changes one of the settings and it will automatically update the GUI to reflect the new value.
* Right now we have CSettings and CGUISettings. With this we'll still have CSettings which is responsible for properly setting up the new settings system and acts like a front for it. The new settings system is accessed and controlled through CSettingsManager but it can and should only be used by CSettings. CGUISettings is completely gone.
* The new settings system only provides CSettingBool, CSettingInt, CSettingNumber and CSettingString. But it allows to specify "custom" setting types which must be derived from CSetting. We additionally provide CSettingPath and CSettingAddon. The reason for this seperation is to keep the new settings system as clean from any XBMC-specific stuff as possible. It also should make it easier to add a new setting type in the future if necessary.
* The GUI representation of the settings basically looks the same. The only difference is that CGUIWindowSettingsCategory now also supports two actions: "settingsreset" will show a confirmation dialog and then reset all the currently visible settings to their default value. "settingslevelchange" allows to cycle through the newly available settings levels (Basic, Standard, Advanced, Expert). The default level is "Standard" and it doesn't show all the settings that are currently visible. With this we can also consider adding more complex settings but we can hide them from the average joe users. These two actions are available in confluence through a sidebar. Furthermore it is possible to define help descriptions for every setting. These can be triggered in the GUI when a setting is active by pressing the "I" key. The integration into the skin will need some help from @Jezz_X or anyone else who has an idea on how to best integrate it.

Especially the XML definitions of the settings are completely new compared to the current system and they can become quite complex with all the different things that can be defined/specified like dependencies on other settings etc but it saves a lot of coding and I tried to keep it as simple as possible. Once this has been merged I'll start working on a wiki page that describes the XML definition of settings and how the whole thing works in general.

There are also a few more things on my TODO list for this (like moving the whole settings system into its own lib as suggested by @TheUni) but they are all nice to have and not essential.

Have fun reviewing this ;-) and as always I'm thankful for any feedback and feel free to ask if anything is unclear concerning the whole setup/system.