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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
