[Development] Settings API for QML

[Nurmi J-P]

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.
> 
> Simon
> 
> 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:
>>> 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.
> 
> 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
>> updates?
>> 
>>     * If shared, does an application have control over when changes are
>> propagated?
>> 
>> * 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. :)

--
J-P Nurmi