[Development] Settings API for QML
jpnurmi at digia.com
Sat Jun 22 12:16:27 CEST 2013
On Jun 22, 2013, at 9:02 AM, Hausmann Simon <Simon.Hausmann at digia.com> wrote:
> You're right, the language extension can be totally separate from settings at the moment. It makes indeed most sense to land things in pieces like you proposed.
> Alan Alpert <416365416c at gmail.com> wrote:
> 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
As Alan clarified, the proposal is to provide a stopgap solution via the labs module.
I think we all agree that it's currently unnecessarily tedious for QML application developers to bake their own persistent settings solutions. Personally I've done it so far in quite a few QML apps using either QSettings in C++ or LocalStorage in QML.
While QSettings has its flaws and limitations, it can handle the main use case (simple persistent settings backend without notifications, bells and whistles) just fine. IMHO it's a matter of documenting the limitations and stating clearly that it's not a full-blown publish and subscribe system. Furthermore, keeping the API minimal and QSettings-agnostic might even make it possible to port it over to the mighty new settings system once someone implements it. :)
More information about the Development