[Development] Settings API for QML

[Nurmi J-P]

On Jun 22, 2013, at 12:16 PM, Nurmi J-P <jpnurmi at digia.com> wrote:

> 
> 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
> 


Hi,

By using property aliases the syntax becomes actually quite neat:


    import QtQuick.Window 2.1
    import Qt.labs.settings 1.0
    
    Window {
        id: window
    
        width: 800
        height: 600
    
        Settings {
            category: "window"
    
            property alias x: window.x
            property alias y: window.y
            property alias width: window.width
            property alias height: window.height
        }
    }


Fully declarative, and it just... works. Props to Jens for the awesome idea! :)

The initial values can be specified (width, height) or left out (x, y). Settings will be automatically stored when the values change (done lazily, a batch of resize/move events in the above example triggers only one change to QSettings).

Now I'd like to invite interested parties to review https://codereview.qt-project.org/#change,59149.

--
J-P Nurmi