[Development] Settings API for QML

[Thiago Macieira]

On terça-feira, 11 de dezembro de 2012 14.51.31, Alan Alpert wrote:
> 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 ;) .

We can define the QML API for the features provided in QtCore inside the QtQml 
library or as a plugin to it. I believe we call those "imports" :-)

The point is that we can develop those two at the same time, with the same 
team, who understand the problems being solved and how to best do exactly 
that.

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

I'm not sure I agree. 

If we choose to expose an *API* in QML that provides simple, local storage and 
local settings similar to those of HTML 5, there's nothing stopping us from 
adding more API later for more complex tasks. We just need to take care to 
define what the boundaries are and how the two integrate. And we might end up 
in the case of having a powerful API that is just as easy as the simple and 
limited API, in effect deprecating it. For that reason, I highly recommend not 
rushing through this and doing it right instead.

Now, adding QML language constructs for a limited use-case seems like a 
complete shot on the foot to me. I'd reserve language constructs for when we 
need them really and be conservative about adding more.

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

I disagree that the latter is more pressing. Isn't there local storage 
already? In what ways is it insufficient? Doesn't it serve as stop-gap until the 
proper research is made?

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

Indeed, which in my mind shoots down the option of developing the two 
separately. If they need to interoperate, they need to be designed with that 
in mind.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/b865f194/attachment.sig>