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