[Development] Settings API for QML

Mark markg85 at gmail.com
Tue Dec 11 09:41:48 CET 2012


On Tue, Dec 11, 2012 at 5:46 AM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On segunda-feira, 10 de dezembro de 2012 19.51.32, Alan Alpert 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.
>
> Before we do settings for QML, we need to figure out what to replace QSettings
> with. Or, better yet, we do the two at the same time: we develop the new C++
> and QML settings APIs at the same time.
>
> Last time this discussion came about, we ended up concluding there's a lot of
> value in the Publish and Subscribe API, so I'd start there for prototyping.
>
>> 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).
>
> This might be able to save and store simple settings local to the application,
> but it will fall apart when the application needs to access settings shared
> with other applications or the system. We need a proper API to read system-
> wide settings.
>
> I'm not sure we should bundle that with Windows registry API, though, like
> QSettings is.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

Perhaps it's an idea to look at KConfig for Qt inclusion? KConfig (XT)
seems nice and works rather well in KDE applications. All that's
needed then is a QML API to access the KConfig configuration. If i'm
right, KDE already has that through data engines though that probably
doesn't work. Perhaps a global Qt QML function like "Qt.config(...)"
or "Qt.configValue(...)" would need to be introduced.

As for QSettings, wasn't it supposed to be deprecated in Qt5?



More information about the Development mailing list