[Development] Settings API for QML
thiago.macieira at intel.com
Wed Dec 12 00:25:49 CET 2012
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
> 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
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development