[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KConfig revisited
From: "Thomas Braxton" <kde.braxton () gmail ! com>
Date: 2007-08-28 10:07:40
Message-ID: 928c3f1b0708280307t6f201583m58a3e56206535a58 () mail ! gmail ! com
[Download RAW message or body]
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.
[Attachment #3 (text/html)]
<br><br><div><span class="gmail_quote">On 8/28/07, <b class="gmail_sendername">Jos \
Poortvliet</b> <<a href="mailto:jos@mijnkamer.nl">jos@mijnkamer.nl</a>> \
wrote:</span><blockquote class="gmail_quote" \
style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> \
<div><span class="e" id="q_114abdd23c240639_0">On 8/27/07, <b \
class="gmail_sendername">Thomas Braxton</b> <<a \
href="mailto:kde.braxton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">kde.braxton@gmail.com </a>> \
wrote:</span></div><div><div><span class="e" id="q_114abdd23c240639_2"><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'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. \
</div><div>So what do you think, should I merge or just forget about \
it?</div></blockquote></span></div><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><div>Thomas</div><div><br> </div>
</span></blockquote></div><br>
</blockquote></div>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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic