[Development] Settings API for QML

[Alan Alpert]

On Tue, Dec 11, 2012 at 6:36 AM, Stephen Kelly <stephen.kelly at kdab.com> wrote:
> On Monday, December 10, 2012 20:46:19 Thiago Macieira wrote:
>> 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.
>
> I agree with this, of course.
>
> QML functionality should not be designed in a walled-garden. 'New age' Qt APIs
> should include C++ APIs as a consideration at least.

I agree with this, of course. But let me define some key terms here:

Functionality: The ability to perform a specific action.

API: The types which expose functionality.

The reason why most QML APIs are developed separate from C++
considerations is that there's already a C++ API for that
functionality. For new functionality QML and C++ APIs should be
developed side-by-side where possible. Except for QtCore (or anything
else that QtQml depends on), which brings us back to QSettings ;) .

This means Thiago is sort of right. We first need to decide how this
functionality should work (somewhat abstract from QML and C++ APIs)
and then we need to develop the C++ and QML APIs for it. But I think
there are two different capabilities being conflated here:

Firstly the system wide fully-fledged settings access, which I believe
is the one we need to redevelop completely because QSettings isn't
cutting it anymore.

Secondly the convenient way to store some application local settings.
I don't know if QSettings is still good for that, or whether it needs
to be replaced.

We'll eventually need both in QML, but I think there's a much more
pressing need for the latter functionality first. The question then
is: do we need to start doing that functionality from scratch
including a C++ API, or is QSettings still good there and QML can just
build its own on top (just writing into an ini file)?

One thing that I started thinking about though is that we will need in
this case to have a C++ and QML API that can work with the same
settings (unlike the existing Local Storage API), so that the C++ and
QML halves of an application can work together properly. It doesn't
mean the APIs have to be at all similar, but they need to easily load
and save to the same data store per application.

--
Alan Alpert