AW: [RFC] KConfig merge

[Nhuh Put]

> Von: Allen Winter
> Gesendet: Montag, 1. Oktober 2007 22:52
> An: kde-core-devel at kde.org
> Betreff: Re: [RFC] KConfig merge
> 
> 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

Ok, later then expected, but I'm ready.
/branches/work/kde4_kconfig/kconfig (the rest of kde4_kconfig is outdated)
It's basically a large refactoring of KConfig.
There are still some overloads for some methods missing, but this half an
hour of work.
Unfortunately I can't really test it and I also don't have the compile power
to port very much myself. In most parts it's only KConfigBase->KConfig.
It would be really nice to have this, because it's not possible in a BC, but
nobody will die, if this isn't in KDE 4.
So the question if, weather I can import it into trunk. If yes, some helping
hands with lots of compile power would be nice.

	PutHuhn