[RFC] KConfig merge

[Allen Winter]

On Monday 01 October 2007 3:45:36 pm Thomas Braxton wrote:
> Hi all,I've got KConfig & friends to an API that I think is stable. I would
> like to merge this today, but I won't have time since I go to work soon.
> Most of the code from previous KConfigBase/KConfig is still there just moved
> around. Alot of the code was moved around to have only 1 place where
> something was done, instead of 3 or 4. The only part of the API that isn't
> stable is KConfigBackend, since there aren't any other backends yet, I don't
> know what kinds of changes will have to be made.
> 
> The only binary incompatible changes are removing
> KEntry/KEntryKey/QMap<KEntryKey,KEntry> from the public API (implementation
> details of KConfig/KConfigBackend) and removing KConfigBase from the
> hierarchy, since it was pretty useless anyway (since KConfigGroup doesn't
> derive from it anymore), I thought that if it was still wanted it could be
> moved to kde3support and made to derive from KConfig to maintain
> functionality, otherwise just delete it. ATM KConfig doesn't have any
> virtual methods except ~KConfig/virtual_hook, not needed right now since
> there shouldn't be a need to derive from KConfig anymore, but I left them
> just in case.
> 
> There are a few source incompatible changes:
>   - Renamed the values of KConfig::OpenFlag because the other names didn't
> really describe their function. To me NoGlobals is the same as not oring
> with IncludeGlobals so I changed it to CascadeConfig, I think Cascade or
> OpenCascade would be a better name, but I'm not sure. Changed OnlyLocal to
> SimpleConfig to reflect the fact that this mode replaces KSimpleConfig.
> Added FullConfig as the default to KConfig
> constructors(=IncludeGlobals|CascadeConfig).
>  - Renamed KConfigGroup::group() to name(), asking a group for it's group
> doesn't make sense unless we have nested groups, asking a group for it's
> name does.
> - There is no KConfig(const char *resource, QString file, ...) constructor,
> what was the purpose of this? There's already KConfig(QString file,
> OpenFlags, const char* resource,...), if the other one is really neccessary
> it can be put back?
> 
> I think this really needs to be merged before the freeze, but since I've
> been sick this weekend I couldn't get this looked at sooner. To try it out
> replace kdelibs/kdecore/config with  /branches/work/kde4_kconfig/kconfig and
> apply the kconfig/diff/kdelibs.diff patch to compile kdelibs. There are also
> patches for kdepimlibs and kdebase, I'm not sure kdebase.diff is complete
> since I couldn't get it to compile completely because of something wrong
> with my soprano setup.
> 
> So have a look and if you feel it needs to be merged, go ahead, I'll be at
> work and won't be able to read my mail 'til after midnight.
> 
PutHuhn has volunteered to put the effort into finishing the KConfig changes,
but it will take him longer than midnight to finish... probably around noon in Europe.

Does anyone object to a BIC commit of the KConfig changes a little past the 
normal Monday deadline?

I think we should permit this to happen.

-Allen