[Development] Settings API for QML

Pier Luigi pierluigi.fiorini at gmail.com
Wed Jul 31 08:38:54 CEST 2013


2013/6/22 Nurmi J-P <jpnurmi at digia.com>:
>
> As Alan clarified, the proposal is to provide a stopgap solution via the labs module.
>
> I think we all agree that it's currently unnecessarily tedious for QML application developers to bake their own persistent settings solutions. Personally I've done it so far in quite a few QML apps using either QSettings in C++ or LocalStorage in QML.
>
> While QSettings has its flaws and limitations, it can handle the main use case (simple persistent settings backend without notifications, bells and whistles) just fine. IMHO it's a matter of documenting the limitations and stating clearly that it's not a full-blown publish and subscribe system. Furthermore, keeping the API minimal and QSettings-agnostic might even make it possible to port it over to the mighty new settings system once someone implements it. :)

Here's my implementation which I started last year and finally managed
to move into its own repo:

https://github.com/hawaii-desktop/qtconfiguration

It's still primitive but it's aimed at providing persistent storage
and notifications for both C++ and QML.

A JSON file would contain settings schema definition, here's a couple
of examples:

https://github.com/hawaii-desktop/shell/blob/master/data/settings/org.hawaii.greenisland.json
https://github.com/hawaii-desktop/vibe/blob/master/data/settings/org.hawaii.desktop.json.in

There's certainly a lot of prior art for settings, and I was inspired
by GSettings.

The QConfiguration class doesn't do much at the moment, it's just a
dumb frontend to QSettings that checks whether a key exists in the
schema and the value() method gets a default value from the schema
when there's no value.
The settings file is reread when it changes.

Ideally the backend should be a plugin.

There's no need to do yet another storage format for settings, we
could use dconf on Linux, registry on Windows and plists on MacOS.

Maybe QConfiguration could read the schema definition and dynamically
alter the meta object creating read/write properties if it's possible.
That should be compatible with Qt.labs.settings except you don't
define properties through QML anymore.

Schema definitions might also be versioned and an automated tool could
migrate settings stored in an older version to the newer version.

I plan to do some cleanup and implement a dconf backend soon.

If you think that the QConfiguration approach is fine maybe we can put
it in the Playground.

--
Out of the box experience
http://www.maui-project.org/



More information about the Development mailing list