[Development] QSettings refactor updates

[Thiago Macieira]

On Monday 13 October 2014 13:46:21 André Somers wrote:
> Personally, I think that using string-based key-value pairs (whether the 
> key has grouped semantics or not) and then manually casting the value to 
> the needed everywhere you need it simply has no place in application 
> code in all but the simplist applications. API's need to be type-safe if 
> at all possible, and if not, the exposure to the non-type safe API 
> should be kept to a minimum. Further more: default values need to be 
> consistent. Allowing the application to access the backend from more 
> than one place, also means having the specify the default value for 
> settings in more than one place. That *will* lead to inconsistencies. In 
> our case, that means that there is only one class where there is 
> exposure to the non-type safe QVariant-based API of Qt, and that is the 
> settings class itself. The rest of the application has no clue, nor 
> needs to have any clue, on how the settings are stored: they are just 
> using type-safe properties with clearly defined default values.

I agree that we should have a code generator on top of a schema, so we have 
the defaults, types and key names centralised in one place.

However, all of that builds on top of a central string-based API, which is 
required. The schema and code generator can come later.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center