On Sat, Jun 22, 2013 at 12:38 PM, Alan Alpert <[email protected]> wrote:

> On Fri, Jun 21, 2013 at 2:24 PM, Jeremy Katz <[email protected]>
> wrote:
> > On 06/21/2013 09:58 AM, Hausmann Simon wrote:
> >> Hi,
> >>
> >> I like this, but as a next step I think it would be good to get rid of
> the manual JS code for saving.
> >>
> >> What about a general syntax of annotating properties? Then settings
> could be implemented on top by introspecting for properties annotated with
> settings tags and then save/restore then.
>
> My biggest concern about that approach right now is the scope of the
> change. We can't back out language features as easily as we can a
> module.
>
> I'd approve adding a Qt.labs.settings element, with the API specified
> by JP, because it gives us what we need and is the most easily
> changeable. If we get to annotating properties, we drop the
> Qt.labs.settings element (after a period of deprecation). We can play
> around with the backend so long as the QML API works, because while a
> consistent and reliable on disk format is important for a complete
> API, for a labs module I'm happy with just the QML API while we figure
> out other implementation details.
>
>
So I haven't really been following this conversation much but by amazing
coincidence I not long ago happened to cobble together something that has
an API very similar to what JP is proposing, it's worked quite well for me
and I can thoroughly recommend the approach.

So if anyone's interested in a proof of concept I have one. Although it is
implemented using gconf for reasons of circumstance so not an actual
implementation proposal. And the code split between two repo' is a little
unfortunate, but hey the (mostly) same API works with c++ too.

https://github.com/nemomobile/nemo-qml-plugin-configuration/pull/2
https://github.com/nemomobile/mlite/pull/4


Andrew
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to