Thx J-P, I was reading Settings documentation and I have just stumbled on the following sentence:
"Writing a setting value using one instance of Settings does not update the value in another Settings instance, even if they are referring to the same setting in the same category.” This is ultra limiting. My current approach relies precisely on this features. I have a QSettings class exposed to QML and every time I change a setting on a side of the code, the setting is automatically propagated across all the respective binded properties. Thanks On 17 Oct 2014, at 10:11, Nurmi J-P <jpnu...@theqtcompany.com> wrote: >> On 17 Oct 2014, at 10:48, Nuno Santos <nunosan...@imaginando.pt> wrote: >> >> Hummm >> >> This Settings QML type is awesome and I didn’t knew it. I had a QSettings >> class exposed to QML and I was declaring all the properties I needed. This >> really saves a lot of work. Should I really on it for a production product? >> > > Hi, > > The reason why QML Settings was placed in Qt.labs is that it's also based on > QSettings. The problem with QSettings is that it doesn't provide change > notifications. QML Settings is indeed very useful, but still far from > optimal. :) It's safe to use in the sense that it's not going anywhere at > least for the lifetime of Qt 5, but a better alternative is expected to > arrive later. > > The API of QML Settings was intentionally kept to the absolute minimum in > order to be able to switch the backend later. Even though it's still not yet > clear how things would look like with the new config system replacement > (which is by the way once again being discussed on the development list). > > -- > J-P Nurmi > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
