<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 31, 2016 at 1:46 PM, Dirk Hohndel <span dir="ltr"><<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, Jul 30, 2016 at 09:14:10PM -0300, Tomaz Canabrava wrote:<br>
> ><br>
> > Would you create a short writeup how the wrapper objects should be used?<br>
> > I'll admit that I feel less then clear about this right now.<br>
> ><br>
> > For each of the seperate types, should there be only one instance of these<br>
> > objects in the running application? Or can any class create their own<br>
> > wrapper object and things will still work correctly (somehow I doubt that,<br>
> > looking at the way this seems to work with the change notifications).<br>
> ><br>
> > But if it's a single instance only, then why aren't there instance()<br>
> > functions for them?<br>
> ><br>
> > I guess I'm confused :-(<br>
> ><br>
> > My example:<br>
> ><br>
> > cloudstorage.cpp creates a CloudStorageSettings object and uses that to<br>
> > make sure that the verification status is maintained correctly. But<br>
> > another part of the CloudStorageSettings is prefs.git_local_only /<br>
> > CloudStorageSettings::gitLocalOnly() - and that needs to be accessed from<br>
> > multiple locations.<br>
> ><br>
> > So if I want to connect a function with the gitLocalOnlyChanged() signal<br>
> > (which, oh, btw, currently isn't sent when that preference is changed),<br>
> > then how do I do this? Clearly creating a separate object isn't going to<br>
> > do the right thing... so I think this needs to indeed be a glabal<br>
> > instance.<br>
><br>
> I had to re-read the code since there's a long time since I don't do<br>
> anything proper for subsurface, so here it goes.<br>
><br>
> There's one SettingsObjectWrapper, that is a singleton, and you use it to<br>
> access everything.<br>
><br>
> If you wan't to access *some* specific property, and deal with the property<br>
> changes you would do:<br>
><br>
><br>
> SettingsObjectWrapper *prefs = SettingsObjectWrapper::instance();<br>
><br>
> // connect the desired preference to some method, the preferences are<br>
> grouped by structs, so it's easy to find the one you need.<br>
><br>
> connect(prefs->cloud_storage, &Signal, this, &MyMethod);<br>
><br>
> set the desired preference:<br>
><br>
> prefs->cloud_storage->setSomething( blah );<br>
><br>
> this will trigger the changed signal on the CloudStorageSettings object<br>
> that in turn will call the slots.<br>
<br>
</div></div>Ah, that's brilliant. Foolish me was instantiating the sub-objects and<br>
then things didn't work as expected.<br>
<br>
Thanks, that was exactly the explanation I was hoping for. Now I can redo<br>
a couple of patches I did in the last couple of weeks and have them<br>
interact with the preferences as intended :-)<br>
<span class=""><br>
> I'm working on that particular code right now, so I'll change all other<br>
> parts of the code that deal with preferences and make it sane again.<br>
<br>
</span>Thanks. Much appreciated. We missed you :-)<br></blockquote><div><br></div><div>I was missing myself. :)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
/D<br>
</font></span></blockquote></div><br></div></div>