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

[joao.abecasis at nokia.com]

Alan Alpert wrote:
> On Fri, 18 Nov 2011 01:34:02 ext João Abecasis wrote:
> > I have a very basic working prototype for a generic Settings API for
> > QML that I would like to bring up for discussion.
> >
> > The API is pretty minimal, here's example usage:
> >
> >     Rectangle {
> >         id: main
> >         height: 480
> >         width: 640
> >         color: settings.color
> >
> >         Settings {
> >             id: settings
> >             property string color: "blue"
> >             property alias height: main.height
> >             property alias width: main.width
> >         }
> >     }
> >
> > I pushed the code to a clone of the Desktop Components repository
> > over on gitorious. There's some further information in the commit
> > message:
> >
> > https://qt.gitorious.org/~biochimia/qt-components/biochimias-desktop
> > /commit/c1ac32929065f24783f4d254d1786dce8202b274
> >
> > While this needs further refinement and exploration (e.g., ignore
> > the fact that it is using QSettings underneath ;-), what do people
> > around here think of this approach?
> 
> The idea is good, but I don't like the use of aliases in the example.
> If you wanted to arbitrarily save/load properties perhaps an attached
> object would be more appropriate, something like:
> 
> Rectangle{
>         height: 100
>         width: 100
>         Settings.persist: ["height", "width"] //If saved data
> available, sets on creation. Saves data on destruction.
> }
> 
> It's not just the complexities of aliases, the data really is in the
> Rectangle element and that's where it should be seen to persist - not
> due to some magic in a Settings element buried randomly in the code.

How would you handle data that is read from Settings, but not saved
back? An example is the color element in my example above.

The idea here is to provide a way to gather (and save) information from
a (platform-specific) standard location and be able to use it seamlessly
in QML applications. The possibility to use aliases is an admittedly
very cool side effect.

> If you just want to save data back and forth, the Settings like object works
> well though. Presumably you'd want to have a way to explicitly save/load the
> data if you don't want to use the platform backend?

Well, the way I want it, there should be nothing but a platform-specific
backend. I don't want this to become a generic file loading/saving
mechanism.

Also, for platforms where this is supported (not with QSettings,
though), runtime changes to configuration data could be transparently
fed back to the application.

> 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 ;)
>         Settings{
>                 group: "Alpha"
>                 Settings{
>                         group: "Beta"
>                         property int foo: 34
>                 }
>         }
> }
> 
> Would save [Alpha/Beta] foo=34 (or whatever).

What's the use case for being able to specify a filename? Is it just
because QSettings can?

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.

Other than that, group functionality is already provided. With the
current implementation your example could equally well be written as:

    Settings {
        group: "Alpha/Beta"
        property int foo: 34
    }

> If you don't want to prototype it with QSettings, perhaps you should use the
> offline storage API like SameGame. It would still be a nice convenience item
> to automatically store and load properties from SQL. Then you could also
> prototype it in pure QML.

I'm looking into some sort of Settings API that can be used from both
the QML and C++ side. Also, on a platform where settings end up in a
central location or where there are external means to change the data, I
want that to remain available and the QML Application to notice those
changes.

Cheers,


João