[Development] Settings API for QML

[Alan Alpert]

On Tue, Dec 11, 2012 at 3:25 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> 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.

I completely agree with you in theory. This is the best solution when
it works. Sadly QML and C++ APIs are still on different paces, because
QML is catching up with existing C++ functionality. If QML had
something as good as QSettings (and could afford to wait), or if the
QSettings replacement was being actively worked on (so there was
minimal wait), then the paces might match. But I don't anticipate the
paces matching for a while yet. QML has a much bigger hole here than
C++, which still has an old API that works.

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

I agree with you here, certainly shouldn't add language constructs
just for this at this stage. Perhaps this new API could be a Qt.labs
module in anticipation of a great new Settings API later? We'd still
have the option of promoting it if the powerful API ends up not quite
as simple as the basic one.

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

There is local storage already. It is insufficient in terms of
usability for this usecase, and thus it isn't really serving well as a
stop-gap until the proper research is made. The usability of the
LocalStorage API is terrible because it is an SQL database and that
means immense (relatively) overhead for just storing a couple of bools
or ints. An SQL database is a terrible choice for that, and as it was
originally an HTML5 API they probably just accepted that because HTML5
has cookies for quick local storage of small things. Maybe we could
add cookie support as a stop-gap measure, but that's probably just
going to be another thing we end up regretting.

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

It doesn't shoot down that option entirely. It may make it less
desirable, but there are file formats like .ini and .json which have
existing C++ APIs to read them. Interoperating on the same data
doesn't necessarily require interoperating using the same APIs. If a
QML only API wrote JSON files to a known location on disk, C++ parts
of the application could still easily use those files (it would
certainly be easier than trying to access the database generated by
the current LocalStorage API).

--
Alan Alpert