On 16/05/2016 8:44 AM, Joseph Lee wrote:
1. Perhaps some add-on authors feel their config code should not be managed by the central Configuration Manager - perhaps they load settings when an add-on loads, used only for configuration and so forth.Sure, but that's not a reason for not using the central system. By that logic, NVDA should store the configuration for every synthesiser in a separate configuration file, since it might not get used until the synth is loaded. In practice, that just isn't scalable and doesn't make sense.
2. I'm a heavy user of my own config code because the config routines are part of an app module. I believe that configuration for app modules should only be accessible (and mutatable) as long as the app in question is running.Why does that actually matter?
This guarantees that NVDA will do its own thing until the app module is loadedIt will anyway; it won't do any different because your config section is present.
at which point it can use the app module's config routines (I've also written some optimizations, namely preventing the config from being written to disk if no settings have changed, which helps in prolonging life of solid-state drives).Arguably, every app module having its own config is actually worse for SSD than using the central system.
3. There is an important issue with the current Config Manager initialization code: you can create multiple instances. I think we should avoid this (theI guess we could, though I think it's simpler just to document that it should be a singleton and should not be instantiated by others (which I see isn't documented; ug).
simplest solution is defining a __new__ function that'll make sure singleton pattern is enforced (will need to rease a ticket regarding this issue)).
As for add-ons using the central config: I'd say add-on authors are not ready to abandon their config code or understand the idea that NVDA already has a configuration routine and they should trust NVDA Core to handle add-on configurations. Also, I think we need some example code that'll tell add-on authors that it is indeed safe to rely on Config Manager (one example that I can think of is somehow telling the OCR add-on to trust Config Manager when storing settings).One of the big advantages of using central config is that you get support for config profiles for free. Conversely, if you don't want config profiles, that's one case where you probably don't want to use the central config.
