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

List:       kde-core-devel
Subject:    KConfig revisited
From:       "Thomas Braxton" <kde.braxton () gmail ! com>
Date:       2007-08-27 16:00:52
Message-ID: 928c3f1b0708270900n310a3a26pd01c5b8181150d60 () mail ! gmail ! com
[Download RAW message or body]

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?

Thomas

[Attachment #3 (text/html)]

<div>Hi</div><div>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&#39;t able to finish. I \
haven&#39;t jumped back in to KDE development because I still don&#39;t have a \
permanent net connection. I&#39;ve been trying to follow what&#39;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&#39;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&#39;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&#39;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. \
</div><div>So what do you think, should I merge or just forget about \
it?</div><div><br class="webkit-block-placeholder"></div><div>Thomas</div><div><br \
class="webkit-block-placeholder"></div>



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