correctly using the preferences wrapper objects

Dirk Hohndel dirk at hohndel.org
Sun Jul 31 09:46:23 PDT 2016


On Sat, Jul 30, 2016 at 09:14:10PM -0300, Tomaz Canabrava wrote:
> >
> > Would you create a short writeup how the wrapper objects should be used?
> > I'll admit that I feel less then clear about this right now.
> >
> > For each of the seperate types, should there be only one instance of these
> > objects in the running application? Or can any class create their own
> > wrapper object and things will still work correctly (somehow I doubt that,
> > looking at the way this seems to work with the change notifications).
> >
> > But if it's a single instance only, then why aren't there instance()
> > functions for them?
> >
> > I guess I'm confused :-(
> >
> > My example:
> >
> > cloudstorage.cpp creates a CloudStorageSettings object and uses that to
> > make sure that the verification status is maintained correctly. But
> > another part of the CloudStorageSettings is prefs.git_local_only /
> > CloudStorageSettings::gitLocalOnly() - and that needs to be accessed from
> > multiple locations.
> >
> > So if I want to connect a function with the gitLocalOnlyChanged() signal
> > (which, oh, btw, currently isn't sent when that preference is changed),
> > then how do I do this? Clearly creating a separate object isn't going to
> > do the right thing... so I think this needs to indeed be a glabal
> > instance.
> 
> I had to re-read the code since there's a long time since I don't do
> anything proper for subsurface, so here it goes.
> 
> There's one SettingsObjectWrapper, that is a singleton, and you use it to
> access everything.
> 
> If you wan't to access *some* specific property, and deal with the property
> changes you would do:
> 
> 
> SettingsObjectWrapper *prefs = SettingsObjectWrapper::instance();
> 
> // connect the desired preference to some method, the preferences are
> grouped by structs, so it's easy to find the one you need.
> 
> connect(prefs->cloud_storage, &Signal, this, &MyMethod);
> 
> set the desired preference:
> 
> prefs->cloud_storage->setSomething( blah );
> 
> this will trigger the changed signal on the CloudStorageSettings object
> that in turn will call the slots.

Ah, that's brilliant. Foolish me was instantiating the sub-objects and
then things didn't work as expected.

Thanks, that was exactly the explanation I was hoping for. Now I can redo
a couple of patches I did in the last couple of weeks and have them
interact with the preferences as intended :-)

> I'm working on that particular code right now, so I'll change all other
> parts of the code that deal with preferences and make it sane again.

Thanks. Much appreciated. We missed you :-)

/D


More information about the subsurface mailing list