[Development] Settings API for QML

[Saether Jan-Arve]

> -----Original Message-----
> From: development-bounces+jan-arve.saether=digia.com at qt-project.org
> [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org]
> On Behalf Of Alan Alpert
> Sent: 12. desember 2012 21:33
> To: Mark
> Cc: development at qt-project.org; Bache-Wiig Jens
> Subject: Re: [Development] Settings API for QML
> On Wed, Dec 12, 2012 at 2:13 AM, Mark <markg85 at gmail.com> wrote:
>> On Wed, Dec 12, 2012 at 10:03 AM, Simon Hausmann
>> <simon.hausmann at digia.com> wrote:
>>> On Tuesday, December 11, 2012 04:40:50 PM Bache-Wiig Jens wrote:
>>>>>> ...
>>> I think a dedicated syntax has two distinct advantages over a
>>> Qt.storedProperty alike approach:
>>> 
>>>     (1) In a distinct syntax we can avoid loosing the type
>>> information and instead preserve and propagate it into the settings
>>> backend. Preserving as much type information as possible is going
>>> to be crucial for performance optimizations in the future.
>>> 
>>>     (2) A syntax would allow for sensible group and avoiding
>>> repetitive patterns in the settings names. In your example writing
>>> "application.width" and "application.height" is not bad, "application"
>>> is repeated only twice. But if you think of a real world use-case,
>>> then you have "application" repeated many many times, which is prone
>>> to errors ("application" vs. accidentally typing "applcation") and
>>> it's not very readable. Therefore I think a more explicit syntax is
>>> more suitable:
>>> 
>>> PersistentSettings {
>>>     id: mysettings
>>>     group: "org.qt.examples.myapp.geometry"
>>>     property int width: 800
>>>     property int height: 600
>>> }
>>> 
>>> Rectangle {
>>>     width: mysettings.width
>>>     height: mysettings.height
>>> }
>> 
>> How about:
>> 
>> This one would be singleton.
>> PersistentSettings {
>>     id: settings
>>     // All properties defined in here are the "global" properties
>>     property int width: 800
>>     property int height: 600
>>     
>>     // Perhaps enforce that a GroupSettings item can only be
>> constructed within the PersistentSettings item in an attempt to
>> enforce settings to be located in one QML file. Don't know if that's
>> wise or not. Just brainstorming.
>>     GroupSettings {
>>       id: myGroup
>>       property int width: 800
>>       property int height: 600
>>    }
>> }
>> 
>> Then to use it:
>> Item {
>>   width: settings.width
>> }
>> 
>> To use the group settings:
>> Item {
>>   width: settings.myGroup.width
>> }
>> 
>> Just some brainstorming. I do like this syntax! It looks very easy and
>> understandable to use.
> 
> Some of that syntax would just fall out of Simon's proposed item. The
> singleton part at least, if we add QML singletons you can take a
> standard PersistentSettings and make it a global singleton yourself
> (so you could access it via Settings.width anywhere in your
> application. I think that would be a much better way of accomplishing
> that, rather than in the element.
> 
> As for the grouping, it could also be accomplished just with a default
> subgroups property on the PersistentSettings, such than any 'child'
> settings objects inherit the group. e.g.
> 
> PersistentSettings {
>     group: "org.qt.examples.myapp"
>     PersistentSettings {
>          id: geo
>         group: "geometry" //Automatically becomes
> org.qt.examples.myapp.geometry because it's a child of the other item
>     }
>     property PersistentSettings geometry: geo //This line is how you'd
> get the Settings.myGroup.width style syntax yourself }
> 
> So for the most part, you could theoretically get that syntax from
> Simon's proposed item without having to add additional constraints on
> the item everywhere. Just how you use it in your application.
>

I would call it "uri" (or "domain" or something alike). It doesn't need to 
have the concepts of grouping at all, since it can just use QML for that.

PersistentSettings {
    id: appSettings
    uri: "org.qt.examples.myapp"

    PersistentSettings {
         id: geometry
         uri: parent.uri + ".geometry"
    }
}



...or some might prefer this:


PersistentSettings {
    id: appSettings
    uri: "org.qt.examples.myapp"
}

PersistentSettings {
    id: geometrySettings
    uri: appSettings.uri + ".geometry"
}


In addition, I'm not sure how much grouped persistent settings are needed in QML apps. I suspect only a few would really need them, and if they need them they can group it as described in the first alternative. If the data is persisted in a hierarchical structure, it will most likely be stored the same way as if it had explicit group support.

Jan Arve