Re: config listener API ...

On 10/08/2015 11:20 AM, Michael Meeks wrote:
>         But then - the way that calc re-calculates is neither trivial, nor
> extremely susceptible to - "split the loop invariant out" - there is
> some deeply nested recursive goodness called from several places going
> on =) So - hopefully this listener provides a better solution.

Hm, my answer would have been:  "Make sure in the Calc code to determine 
the configuration's UseOpenCL setting at most once per whatever 
top-level (GUI or API) stimulus triggers such re-calculation."  (A 
presumed benefit of that approach would be that all parts of such a 
re-calculation would consistently use the same UseOpenCL value.)

>         Tor's idea of a shared global struct with state is interesting; but is
> quite a big chunk of work I think. It could be split up by path (as now)
> with a struct at the end of each node - but (I imagine) would involve a
> lot of type introspection / wrangling as it's walked; and may make
> startup rather slower too. I'm not sure that configmgr maintains a
> flattened set of its layered data anyway (does it ?).
>
>         Also - the "atomic change set" writing for configmgr settings (although
> cumbersome at first glance) -should- map rather well to the way settings
> dialogs work etc. so - in a global variable / structure world we'd want
> to have that readonly I guess.

I've lost you here.  What would we want to have readonly?