On Fri, Oct 10, 2014 at 6:24 AM, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Friday 10 October 2014 11:07:52 Milian Wolff wrote: > > may I ask why you don't simply copy KConfig? It's API design has proven > to > > be extremely versatile and efficient over the years. > > He is copying KConfig's API. That's why the main class is QConfigGroup, > like > KConfigGroup. > Actually, I'm not - this was a design decision because I didn't tougth of a better way to do it - I didn't even looked at the KConfig api, and the last time I used it was the KConfigXT , years ago. :) > > > So is there any reason > > for writing something from scratch, instead of picking KConfig and adding > > the JSON cache feature on-top? Maybe I'm just missing some context or > > previous discussion on that matter? > > Licensing. > > Unless you're able to contact all the contributors to KConfig and convince > them > to relicense under the CLA for inclusion into Qt, then you have the time to > clean it up. David wanted the same for KStandardDirs, but he ended up > rewriting from scratch for QStandardPaths and the result was much cleaner. > I'm > expecting the same here. > > > Note that KConfig uses a pluggable format in the background, so adding > > registry or plist support is possible. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
