[Qt-qml] Settings / State Saving proposal for QML

[Shawn Rutledge]

On Fri, Nov 18, 2011 at 8:55 AM,  <joao.abecasis at nokia.com> wrote:
> Alan Alpert wrote:
>> If it ends up like QSettings (I can't just ignore that fact ;) ) then you'd
>> probably want to have groups handled through the object hierarchy, e.g.
>> Settings{
>>         file: "settings.ini" //You seem to be missing this property ;)

Windows has registry branches.  Modern Linux is going towards
~/.config/application-name/conf-file (or in some cases
~/.config/company/application-name/conf-file) rather than ini files in
arbitrary places.  And QML apps can be cross platform sometimes.
So...if the backend is going to be QSettings I think it should support
the same features as much as practical, to get good interoperability
between native and Qt Quick apps, or parts of apps.  So to work with
the same ini files / registry branches we also need

organizationName
organizationDomain
applicationName

but maybe it makes more sense to specify them globally rather than in
the Settings object.

>>         Settings{
>>                 group: "Alpha"
>>                 Settings{
>>                         group: "Beta"
>>                         property int foo: 34
>>                 }
>>         }
>> }
>>
>> Would save [Alpha/Beta] foo=34 (or whatever).
>
> As for the object hierarchy, I thought of that. I didn't look too much
> into it and find it ugly anyway. What's the use case for using
> hierarchy? As far as I can see, you'd still need an id per Settings
> object to be able to bind to its values.

I imagine hierarchy was probably invented because of the Windows
registry, but has also been implemented in other ways.  In the case of
ini files, I suspect the support for hierarchy beyond the basic
single-level groups may have been a Qt-specific extension.  In the
registry or in XML it makes sense to have more hierarchy.  Anyway
since QSettings supports it, why leave out stuff that could be useful,
especially since the backend implementation is already done?  As for
QSettings you could use a slash-separated path as the key.  Then you
wouldn't need nested Settings objects.

I assume the QML Settings would support all the usual QML datatypes
too, since QSettings already can handle arbitrary QVariants?

Settings{
       organizationName: "myco"       // only if overriding the global one
       applicationName: "apptastic"   // only if overriding the global one
       group: "main/editpage"    // A path to the appropriate part of
the hierarchy
       pageName: "edit my data"   // should not need the property keyword, IMO
       color: "yellow"       // Let's support every data type that QML does
       undoLevels: 10
       dirty: false
       property alias ... // you could still support that if there's a
valid use case
}

It's succinct, powerful, easy to implement, and omits nothing of what
QSettings can already do for us.  Well except maybe hierarchical keys
within hierarchical groups, because we can't have property names with
slashes in them... but you can still access such keys by doing the
drilldown in the group instead, right?

shawn.rutledge at nokia.com