[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    AW: KConfig revisited
From:       "Nhuh Put" <nhuh.put () web ! de>
Date:       2007-08-28 17:58:58
Message-ID: 004001c7e99d$1c0d4f00$3301a8c0 () spika
[Download RAW message or body]

Von: Thomas Braxton
Gesendet: Dienstag, 28. August 2007 12:08
An: kde-core-devel@kde.org
Betreff: Re: KConfig revisited

> On 8/28/07, Jos Poortvliet <jos@mijnkamer.nl> wrote:
> > On 8/27/07, Thomas Braxton <kde.braxton@gmail.com > wrote:
> > > Hi
> > > My name is Thomas Braxton, you may remember I was the one doing the
refactor on KConfig. Real life got in the way and I wasn't able to finish. I
haven't jumped back in to KDE development because I still don't have a
permanent net connection. I've been trying to follow what's going on in KDE
mostly through the Commit Digest, and I noticed someone is writing a backend
for KConfig. So, I was wondering if the work I was doing is still wanted?
The classes could have been merged a while ago since there was only two
things that didn't work at the time; failing QByteArray test (which I
believe someone else solved in trunk) and locales not fully implemented in
KConfigIniBackend. Now it seems there are some small changes that need to be
made to make it compile with the new interface, but it doesn't seem like
much work. Since someone is actually trying to write a new backend, I
figured the work I did should make it easier. He should only have to
implement 2 functions in a KConfigBackend derived class to make a new
plugin. The biggest changes from the current API would be: removing
KConfigBase (it's superfluous since all KConfigBase objects are also KConfig
objects, no need for a useless abstract base class) and change KEntryMap
from a typedef to a class derived from QMap (this allows to remove some
implementation details from the public API, the only classes that need to
know about the implementation of KEntryMap is KConfig, KConfigGroup? and
KConfig*Backend classes). The two changes above can probably be done today,
the rest of the merging should be able to be done in the next week. 
> > > So what do you think, should I merge or just forget about it?

> > How important is this in the long run, eg could this be done for 4.1,
BC? 
 

> > > Thomas

 

> How important is which part? If someone is writing a KConfigBackend now
then I think this should be merged ASAP so they can use this API instead of
having to figure out how to seperate KConfigBase, KConfig & KConfigBackend
which I've already done. The current classes know way too much about each
other's implementation. That was the main reason I wanted to do the
refactoring, to seperate the functionality of the classes involved, they
were very intermingled and made many assumptions about how things were
implemented in the other classes. There are probably some assumptions still
there, but the only way to find them and remove them would be to have
someone else use the API. 

Hello
I did take a look at the branch, and I have to say, I don’t really like it.
First, it will be much work to merge it with current trunk. KConfigSkeleton
is now in kdeui and can’t be easily
moved back to kdecore afaik because it depends on ui stuff and otherwise it
looks more or less outdated too.
It has also still the setGroup stuff in KConfig and the plan was to get rid
of it afaik, because it can lead to problems.
I also don’t think it’s a good idea to inherit KConfig from KConfigGroup.
And KConfig isn’t really backend independent, it still has functions like
changeFileName and lockFile, which doesn't any
sense on for example an SQL backend or the Windows registry.
Changes on the backend could be handled in a BIC way, I think. We could make
it private API for 4.0 if it isn't already.
Changes on KConfig(Base/Group) would be more important.


	PutHuhn


[prev in list] [next in list] [prev in thread] [next in thread]