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

[João Abecasis]

On Nov 18, 2011, at 11:50 AM, ext Shawn Rutledge wrote:
> 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.

That's not what I meant to say. I don't disagree with supporting hierarchy/categories in the data. With the current implementation that is conveyed by using slashes in the group name.

What I'm not particularly fond of is the use of hierarchy in QML, through nested Settings objects, for this purpose.

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

Yes, I'd prefer that this stays outside the Settings object and is grabbed locally. At the moment, it means that they're not set at all for a QML-only app, which is very unfortunate. I'd prefer that the platform decides the policy here, instead of having to hardwire this information in the code.

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

In general, the model I'd like to push for configuration data is that supported by JSON. If it's supported by JSON, it should be possible to write to, read from and bind.

>  As for
> QSettings you could use a slash-separated path as the key.  Then you
> wouldn't need nested Settings objects.

Exactly. ;-)

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

Whatever is supported by JSON for maximum portability. Not necessarily limited to that. At the moment, the implementation supports whatever QVariant supports and QSettings can persist.

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

The reason for trying to keep some distance from QSettings is exactly that it has flaws and issues. I don't want to be *forced* to use it or re-implement it. Ideally, the backend will be handled by a platform-specific plugin that is *not* QSettings or based on it.

(Also note that there is a wish to remove QSettings from Qt Core in Qt 5, pending availability of something to replace it with.)

Thanks for the comments!


João