From kde-core-devel Tue Aug 28 22:11:36 2007 From: Mickael Marchand Date: Tue, 28 Aug 2007 22:11:36 +0000 To: kde-core-devel Subject: Re: KConfig revisited Message-Id: <20070828221136.GE16283 () kyu ! freenux ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118836558216090 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 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 wrote: > > > > On 8/27/07, Thomas Braxton 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 > > > >