correctly using the preferences wrapper objects

[Tomaz Canabrava]

On Sun, Jul 31, 2016 at 1:46 PM, Dirk Hohndel <dirk at hohndel.org> wrote:

> 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 :-)
>

I was missing myself. :)


>
> /D
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160801/3ebba226/attachment-0001.html>