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

List:       kde-core-devel
Subject:    Re: KConfig revisited
From:       Mickael Marchand <marchand () kde ! org>
Date:       2007-08-28 22:11:36
Message-ID: 20070828221136.GE16283 () kyu ! freenux ! org
[Download RAW message or body]

Hi Thomas,

actually I was the one who started work on it, initially I just wanted to
wrote a SQL backend , so I worked on the backend stuff only.
my first implementation did work, I followed ossi's suggestion to split
kconfigbackend in a kconfigfilebackend and move all the files stuff
there.
That indeed looked much better to me.

I looked a while ago at what you've done last year, but it was so far
away from trunk that I preferred to just get over and use trunk as a
basis to understand the whole thing.

then PutHuhn joined the move (through IRC) and we tried to see how we
could move things around to get a cleaner API and improvments (to
backends, nested groups etc), that's what we are trying to do at the
moment with a first shot of API (branches/work/kconfig_new), we are also
trying to keep the porting effort minimal since we are at the moment in
a "stop huge API changes" period.

I don't think the old branch will be that easy to get back in sync with
trunk, I looked again, there are big differences and I am not sure it's
something do-able without a lot of work. If you can show us something
more in-sync then we probably can see if our ideas can be merged somehow
or get the better out of them.

sorry for my late answer, a bit busy these days ;)

Cheers,
Mik

On Tue, Aug 28, 2007 at 02:08:55PM -0500, Thomas Braxton wrote:
> On 8/28/07, Nhuh Put <nhuh.put@web.de> wrote:
> >
> > 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 said there were a few changes that needed to be made to bring it up to
> date. I don't think it will be that much work, mostly moving some things
> around that have changed, I wasn't asking to merge as it is.
> 
> I also don't think it's a good idea to inherit KConfig from KConfigGroup.
> 
> 
> Huh? I think you got that backwards, KConfigGroup used to be derived from
> KConfigBase. Since I got rid of KConfigBase it's now derived from KConfig,
> but in trunk it was changed while I was gone to not derive from KConfigBase
> anymore (not a problem already changed in my local copy).
> 
> 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.
> 
> 
> for the fileName stuff, I've looked at the code and you use the fileName as
> a namespace (pretty much exactly what I would've expected), so what's the
> problem, keep using it as a namespace. KConfig doesn't care if the fileName
> actually exists, only the backend does. KConfig only uses the fileName more
> or less as a URI. It sounds like with your backend it would have to be "all
> or nothing". the way I have it set up every file except kde4rc can use a
> different backend and can even change backends
> 
> lockFile if you looked at the implementation doesn't do anything, because I
> didn't like the assumptions it makes (not all backends would have a simple
> lockfile), I just never got around to removing it. I was planning on adding
> lock()/unlock() members to KConfigBackend that can be reimplemented as
> necessary how the backend sees fit.
> 
> 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]