[Development] Settings API for QML

[Knoll Lars]

On Dec 11, 2012, at 4:51 AM, Alan Alpert <416365416c at gmail.com> wrote:

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

One idea we had earlier was to use JSON to load and save settings. The advantage would be that it's JS compatible, and we could possibly even load it in a way that you can simply bind to setting values in there.

using sqlite and locastorage doesn't sound like a good match for an API that saves and restores properties.

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

I think a filename for the Settings objects is a requirement. Anything else is going to be a pain for application developers, as they couldn't easily refactor their app between versions without risking to loose the settings.

Cheers,
Lars