[Development] Start of a refactor of the QSettings class based on QJson

[Jeremy]

On 5September2014, at 12:33, Tomaz Canabrava <tcanabrava at kde.org> wrote:

> Long that that I have send this e-mail already, but better late than never.
> In the Qt Develompent Summit I raised my hand to get one dirty thing done: 
> 
> The Settings. 
> 

The general idea appeals to me.


> After a good while with negative time ( Real Work, KDE, Subsurface, and other personal stuff ) I have finally had the time to start.
> 
> For now, I'v implemented two things:
> 
> Parsing from .ini to QJson
> Saving from QJson to .ini
> 
> Why .ini instead of json, since I'm doing a conversion and I coul'd simply store the json file?
> 
> .ini is better to humanreadability.
> thiago asked me to do from ini to qjson


Binary compatibility requires that QSettings for 5.x continue to handle .ini files for all existing functions. Adding json for 5.5 should be fine.


> 
> Issues:
> 
> After a Json tree is constructed, it's hard to modify it's contents:
> 
> QJsonObject rootConfig;
> rootConfig.insert("group1", QJsonObject());
> rootConfig.insert("group2", QJsonObject());
> 
> QJsonObject group1 = rootConfig.vaule("group1").toObject();
> group1.insert("key1", 1);
> rootConfig.insert("group1", group1);
> 
> since I need to take the value, modify it, insert it back nested groups are a pain to use,
> because I would have to chain the removal / addtion of the parent group untill I hit the rootGroup.
> 

QJsonDocument doc = QJsonDocument::fromJson("{ \"name\": \"object\"}");
QJsonObject obj = doc.object();
QJsonValueRef ref = obj["name”];
ref = "object2”;
doc.setObject(obj);


> what I plan to do, besides that:
> - changed the config file from outside of the app, the app should reload it's settings.


What’s the intended change detection mechanism? If it’s a file change, there’s the issue of incomplete updates to handle. I suppose it could ignore anything other than an valid JSON, empty files, and deleted files under the theory that edits of a single entry are less likely to produce valid interim results.

Will changes be announced at the document level, or more fine grained? I think anything beyond the document level is asking for trouble.


> - compile-time check of typos in keys based on a schema ( and not runtime. )
> 
> Help is appreciated, and comments welcome.
> 
> the *temporary* repo with the *temporary and somewhat broken* code:
> github.com:tcanabrava/QConfigNG
>