On Sun, Jul 31, 2016 at 1:46 PM, Dirk Hohndel <[email protected]> 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 >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
