[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 19:08:55
Message-ID: 928c3f1b0708281208n1f512971nee71b0b5992f11a3 () mail ! gmail ! com
[Download RAW message or body]
On 8/28/07, Nhuh Put <nhuh.put@web.de> 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 <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.
>
> 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
>
>
[Attachment #3 (text/html)]
<br><br><div><span class="gmail_quote">On 8/28/07, <b class="gmail_sendername">Nhuh \
Put</b> <<a href="mailto:nhuh.put@web.de">nhuh.put@web.de</a>> \
wrote:</span><blockquote class="gmail_quote" \
style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex">
Von: Thomas Braxton<br>Gesendet: Dienstag, 28. August 2007 12:08<br>An: <a \
href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>Betreff: Re: \
KConfig revisited<br><br>> On 8/28/07, Jos Poortvliet <<a \
href="mailto:jos@mijnkamer.nl"> jos@mijnkamer.nl</a>> wrote:<br>> > On \
8/27/07, Thomas Braxton <<a \
href="mailto:kde.braxton@gmail.com">kde.braxton@gmail.com</a> > wrote:<br>> \
> > Hi<br>> > > My name is Thomas Braxton, you may remember I was the \
one doing the <br>refactor on KConfig. Real life got in the way and I wasn't able \
to finish. I<br>haven't jumped back in to KDE development because I still \
don't have a<br>permanent net connection. I've been trying to follow \
what's going on in KDE <br>mostly through the Commit Digest, and I noticed \
someone is writing a backend<br>for KConfig. So, I was wondering if the work I was \
doing is still wanted?<br>The classes could have been merged a while ago since there \
was only two <br>things that didn't work at the time; failing QByteArray test \
(which I<br>believe someone else solved in trunk) and locales not fully implemented \
in<br>KConfigIniBackend. Now it seems there are some small changes that need to be \
<br>made to make it compile with the new interface, but it doesn't seem \
like<br>much work. Since someone is actually trying to write a new backend, \
I<br>figured the work I did should make it easier. He should only have to \
<br>implement 2 functions in a KConfigBackend derived class to make a new<br>plugin. \
The biggest changes from the current API would be: removing<br>KConfigBase (it's \
superfluous since all KConfigBase objects are also KConfig <br>objects, no need for a \
useless abstract base class) and change KEntryMap<br>from a typedef to a class \
derived from QMap (this allows to remove some<br>implementation details from the \
public API, the only classes that need to <br>know about the implementation of \
KEntryMap is KConfig, KConfigGroup? and<br>KConfig*Backend classes). The two changes \
above can probably be done today,<br>the rest of the merging should be able to be \
done in the next week. <br>> > > So what do you think, should I merge or \
just forget about it?<br><br>> > How important is this in the long run, eg \
could this be done for 4.1,<br>BC?<br><br><br>> > > Thomas<br><br><br><br> \
> How important is which part? If someone is writing a KConfigBackend now<br>then \
I think this should be merged ASAP so they can use this API instead of<br>having to \
figure out how to seperate KConfigBase, KConfig & KConfigBackend <br>which \
I've already done. The current classes know way too much about \
each<br>other's implementation. That was the main reason I wanted to do \
the<br>refactoring, to seperate the functionality of the classes involved, they \
<br>were very intermingled and made many assumptions about how things \
were<br>implemented in the other classes. There are probably some assumptions \
still<br>there, but the only way to find them and remove them would be to have \
<br>someone else use the API.<br><br>Hello<br>I did take a look at the branch, and I \
have to say, I don't really like it.<br>First, it will be much work to merge it with \
current trunk. KConfigSkeleton</blockquote><blockquote class="gmail_quote" \
style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> is \
now in kdeui and can't be easily<br>moved back to kdecore afaik because it depends on \
ui stuff and otherwise it<br>looks more or less outdated too.<br>It has also still \
the setGroup stuff in KConfig and the plan was to get rid </blockquote><blockquote \
class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex">of it afaik, because it can lead to \
problems.</blockquote><div><br class="webkit-block-placeholder"> </div><div>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. </div><div><br \
class="webkit-block-placeholder"></div><blockquote class="gmail_quote" \
style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I also \
don't think it's a good idea to inherit KConfig from KConfigGroup. \
</blockquote><div><br class="webkit-block-placeholder"></div><div>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). </div><br><blockquote class="gmail_quote" \
style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">And \
KConfig isn't really backend independent, it still has functions \
like<br>changeFileName and lockFile, which doesn't any <br>sense on for example \
an SQL backend or the Windows registry.</blockquote><div><br \
class="webkit-block-placeholder"></div><div>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 \
</div><div><br class="webkit-block-placeholder"></div><div>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. </div><br><blockquote \
class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex">Changes on the backend could be handled in a BIC way, I \
think. We could make<br>it private API for 4.0 if it isn't already.<br>Changes \
on KConfig(Base/Group) would be more \
important.<br><br><br> PutHuhn<br><br></blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic