This is more of the settings cleanup work I initially presented in #2190. It adds two new interfaces:
All the newly introduced classes each contain a set of methods that logically belong together and IMO should get their own class to be easier accessible and didn't really belong into CSettings in the first place.
There are more settings that IMO can and should be moved into seperate classes like all the display/GUI calibration, resolution information, profile access etc and I'll start working on those once this has gotten the green light.
Looks fine with a quick scan.
I notice nothing is currently unregistering itself. Perhaps it could do so on app close?
Yeah I forgot to add the unregistering because we clean that array in the CSettings destructor anyway so it never was a problem. But I'll add the calls to keep it clean.
In general, it'd be helpful for android if we could avoid depending on the destructors to clean up too much at exit, since there are a few different notions of what "exit" actually means. dlopen'd libs are a good example of something that presents a problem (lib destruction at exit depends on the loader class still being alive, which leaves us in a very undefined state), and i imagine global settings could do the same.
I see you've agreed above, just figured i'd chime in with something anecdotal for some motivation :)
Btw, what's your plan for this PR? Is it in a state to be merged currently, even with major chunks missing? If so, I'd encourage you to go ahead and shove it in for april and deal with the fallout, then start working on the next steps. That should help with the overwhelmingness some.
If that's the case, imo it'd be worthwhile to declare the last day (or an extra day) of the merge window as yours, and make everyone work around you until you've gotten it in. @davilla suggested this for the unified-dependencies merge, and I think it worked out very well.
This PR does not really have any impact on behaviour or anything. It's just refactoring and moving stuff around. Ideally I'd like to throw it in the first day because I already have another branch which depends on this one with more refactoring etc. The faster I get these things in, the sooner I can go back to the actual settings refactoring work (damn that rebase is gonna be a pain :-/ ).
I don't see why it can't go in April 1 - it'll need some xcode project love but that's about it.
Well, the concern there is that your PR has the potential to interrupt several others. If there's not much in the pipeline that touches this stuff, then of course that's moot.
imo this should indeed go in 1st
I think the other PRs that it might affect can be handled/adjusted more easily than fixing this back if you pull it in the last day.
I've added a commit with the necessary calls to the UnregisterFoo method as requested. I'll check the other PRs currently queued for April and see if there are any potential issues (ignoring project files).
I just made sure this also compiles fine on linux. Had to add two small include fixes.
@Montellese this pr went gray when i was about to sync xcode projects - did a pr to your branch with the needed changes (compile tested osx/ios/atv2).
settings: add ISettingsHandler
CPlayerCoreFactory: implement ISettingsHandler
CRssManager: implement ISettingsHandler
CUPnPSettings: implement ISettingsHandler
CAdvancedSettings: implement ISettingsHandler
settings: add ISubSettings
CSettings: now we can savely call Clear() again from the destructor
CApplication: implement ISettingsHandler
settings: move skin settings into CSkinSettings
settings: move source settings into CMediaSourceSettings
settings: move view state settings into CViewStateSettings
settings: move watched and video settings into CMediaSettings
settings: don't forget to unregister subsettings and settings handler…
[win32] update VS project files
[osx/ios/atv2] - sync xcode projects