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

List:       kde-core-devel
Subject:    Re: KConfig revisited
From:       "Jos Poortvliet" <jos () mijnkamer ! nl>
Date:       2007-08-28 9:44:52
Message-ID: 5c77e14b0708280244r5d9e2d9ap5fcdee750207ab28 () mail ! gmail ! com
[Download RAW message or body]

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
>
>

[Attachment #3 (text/html)]

On 8/27/07, <b class="gmail_sendername">Thomas Braxton</b> &lt;<a \
href="mailto:kde.braxton@gmail.com">kde.braxton@gmail.com</a>&gt; wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <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></blockquote><div><br>How important is this in the long run, eg could this \
be done for 4.1, BC? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <span \
class="sg"><div>Thomas</div><div><br></div> </span></blockquote></div><br>



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