[Development] Settings API for QML

[Alan Alpert]

There was a discussion a while ago about a better settings API for
QML, http://permalink.gmane.org/gmane.comp.lib.qt.qml/3162 was the
best link I could find, but no progress has been made since. The main
concensus I got from that thread was just that no one likes QSettings
(ancient, file-based) and no one uses local storage (just not simple
enough). For just simple, persistent settings there was a need for a
new API. And there still is, since I don't think we agreed on an API
or location for it.

So I'd like to restart the discussion with the suggestion that a
convenience persistent settings API be added to the
QtQuick.LocalStorage module. Basically just a convenient wrapper using
the exact same backend as the LocalStorage type (possibly even
implemented with it in QML).

To get the discussion going, here's my suggestion for that API:
PersistentSettings
{
    property bool loadOnStartup: true
    property bool saveOnExit: true
    function load()
    function save()
}

When save is called (or the item is destroyed and saveOnExit is true)
all properties other than the three it started with (the two bools and
objectName) are saved to disk. When load is called (or item is created
and loadOnStartup is true) all properties previously saved to disk
will have those properties set to the values saved on disk. Typical
usage would not call load/save or set either bool, the settings are
just 'persistent'. E.g in use it would just look like

PersistentSettings
{
    property string lastUser: "Moi"
    property bool useMinimalUI: true
    property int lastDifficultyLevel: 3
}

The real question is whether it over-simplifies the settings usecase,
even for the convenience API. Note that there's no
application/organization name or versioning. The name used internally
would be based on the location of the QML file containing the element,
so the database would be recreated every time you move the file
containing Settings{}. On top of that, properties are likely going to
be converted to strings for storage (both inefficient and ruling out
complete var/variant support). Would this still be worthwhile just for
convenience when you have to set a couple of boolean user preferences?

--
Alan Alpert