xbmc/xbmc — pull request #2190 by Montellese (2013-02-06 23:52:09+00:00)
Title: [RFC] settings reorganisation

This is an extract from my settings refactor work. The branch and changes has become huge and touches so many files that I decided to try to extract some stuff to be able to merge the changes through seperate PRs and to get some feedback on some of the changes I made. So this is more of a "request for comment" for now as there are a lot more similar changes in the settings refactor branch that would fit into this PR but I only included a few here to be able to better show the changes.

This PR contains some reorganisation and two different types of changes. Both have the goal to get logic out of CSettings and into more context-specific classes.
* All CGUIDialog*Settings header/source files have been moved into a seperate directory xbmc/settings/dialogs/ and all CGUIWindow*Settings header/source files have been moved into xbmc/settings/windows/. This is more in line with what we already do in xbmc/music/, xbmc/video/ etc. Furthermore AppParamParser.h/cpp has been moved from xbmc/settings/ to xbmc/ because IMO it doesn't really fit into settings.
* I introduced an interface called ISubSettings which can be implemented by a class which manages certain settings that are stored in guisettings.xml but are not directly GUI settings i.e. they are not handled by CGUISettings. Examples are skin settings, rss feeds, video configuration etc. Classes implementing ISubSettings can register and unregister at CSettings and their implementations of Load(), Save() and Clear() are automatically called whenever guisettings.xml is loaded or saved. As an example I've extracted all skin settings into a new singleton class CSkinSettings. This makes the logic of CSettings easier and would also make it easier to move skin settings from guisettings.xml into a skin-specific XML file (like we do for any other addon).
* CSettings also contains a lot of logic to load other configuration files like upnp.xml or sources.xml etc and all those values are accessible through CSettings. Moving them into seperate classes also cleans up CSettings. As an example I've moved the logic to interact with the configuration values stored in upnp.xml into a new singleton class CUPnPSettings which is placed in xbmc/network/upnp with the rest of the UPnP logic.

IMO these two types of changes provide a way to clean up CSettings which will make it easier to refactor/re-write/replace it later on with a more sophisticated system which will unify the current CSettings and CGUISettings into a single class.

Let me know whether you like the way this is headed or not. It's gonna be hell to rebase the settings refactor branch onto these changes but IMO it's worth it as these changes don't really change any functionality, they just refactor and reorganise the code to make it more modular.