[Development] Settings API for QML
416365416c at gmail.com
Sat Jun 22 04:38:33 CEST 2013
On Fri, Jun 21, 2013 at 2:24 PM, Jeremy Katz <jeremy.k.list at gmail.com> wrote:
> On 06/21/2013 09:58 AM, Hausmann Simon wrote:
>> 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
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.
The need for this feature seems great enough that people are willing
to sacrifice some of the important details in order to get the basic
functionality available to QML now (5.2).
> I feel like discussion of what this is for has taken a secondary
> position to syntax and implementation details.
I feel that the "why" discussion was already solved. The "how" is
coming up again because it's the sticking point. Here's my
understanding of what's needed:
> * Is access limited to the application, shared (system wide or multiple
> scopes?), or both?
Application (although in a more usable format than QtQuick.LocalStorage)
> * If shared, does an application receive notification of external
> * If shared, does an application have control over when changes are
> * Is this targeting a designated storage format, or system (plugin?)
> implementation defined?
No. The storage format is one of the biggest sticking points because
QSettings has no friends anymore. But that's not really useful for the
usecase (given that it is not intended for shared settings).
> * Is the storage meant to be usable by non-Qt applications?
> * Is the storage hierarchical?
> To some degree, all of these have been discussed. Have any conclusions
> been reached, or are we waiting for a decision by implementation?
There are unanswered questions about the implementation, but usually
having something that works trumps those whether we're waiting or not
More information about the Development