> -----Original Message-----
> From: development-bounces+jan-arve.saether=digia....@qt-project.org
> [mailto:development-bounces+jan-arve.saether=digia....@qt-project.org]
> On Behalf Of Alan Alpert
> Sent: 12. desember 2012 21:33
> To: Mark
> Cc: development@qt-project.org; Bache-Wiig Jens
> Subject: Re: [Development] Settings API for QML
> On Wed, Dec 12, 2012 at 2:13 AM, Mark <mark...@gmail.com> wrote:
>> On Wed, Dec 12, 2012 at 10:03 AM, Simon Hausmann
>> <simon.hausm...@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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
