This is a question to Zini.
I am currently implementing proper resolution changing. The RenderingManager now has a listener that gets called when the window size changes. In this listener, I write the new window size to the settings. Now I somehow need to pass this to pretty much all subsystems (InputManager for adjusting mouse clipping size, WindowManager for adjusting HUD size, and so on). I think that it's nasty to call these from the RenderingManager, So, I wanted to ask if I can add a "processChangedSettings(const Settings::CategorySettingVector& changed)" to MWBase::Environment that would call "mInputManager->processChangedSettings(..) ; mWindowManager->processChangedSettings(..)" and so on. Do you agree with that, or otherwise what's your suggestion?
Edit: Or should I simply move the listener to Engine?
Adding a new method to MWBase
Re: Adding a new method to MWBase
No new functions for MWBase::Environment please. We still have plans for this class and including some refactoring with a massive subsystem decoupling.
If the situation would be different, we might want to consider a general purpose broadcasting system (e.g. derive all top-level facade classes from a common base class interface with appropriate messaging functions like your processChangedSettings), then store all the pointers to the facades in a container and run through them with a call to this function. Or something like this. I haven't thought it through completely.
But it doesn't seem to me as we would need such a system. At least for the requested function, only the input system, the gui system and the sound system need to be informed. That hardly qualifies as a broadcast and I don't see any other cases besides your processChangedSettings function where this would be needed.
Unless there are any other cases I have overlooked, I suggest you just call these functions manually for now (if needed, we can still rework it after the refactoring; which may become a post-1.0 task though).
If the situation would be different, we might want to consider a general purpose broadcasting system (e.g. derive all top-level facade classes from a common base class interface with appropriate messaging functions like your processChangedSettings), then store all the pointers to the facades in a container and run through them with a call to this function. Or something like this. I haven't thought it through completely.
But it doesn't seem to me as we would need such a system. At least for the requested function, only the input system, the gui system and the sound system need to be informed. That hardly qualifies as a broadcast and I don't see any other cases besides your processChangedSettings function where this would be needed.
Unless there are any other cases I have overlooked, I suggest you just call these functions manually for now (if needed, we can still rework it after the refactoring; which may become a post-1.0 task though).