[RFC] KConfig API stuff

[David Faure]

On Monday 22 October 2007, Oswald Buddenhagen wrote:
> On Mon, Oct 22, 2007 at 02:08:59PM +0200, David Faure wrote:
> > I'm sorry but there is nothing ugly with KConfigGroup(config, QString()).
> > 
> there is. compare this:
> 
> testrc:
> key1=foo
> [group1]
> key2=bar
> [group1/group2]
> key3=baz
> 
> KConfigGroup cg;
> // mine:
> cg = KConfig("test");
> // yours:
> cg = KConfig("test").group("");
> // the common ground:
> cg.readEntry("key1");
> cg = KConfig("test").group("group1");
> cg.readEntry("key2");
> cg = KConfig("test").group("group1").group("group2");
> cg.readEntry("key3");
> 
> see the inconsistency? doesn't it bother you at all?

Not really. The idea is to separate the KConfig world (which is the file / database / ...)
from the group world (which is where the API for reading and writing invidual keys is). 
To go from the first to the second you have to use .group(...), so this
includes how to get to the root group.
  -- add a .rootGroup() if you want to avoid the empty string there.

Of course both concepts would work in theory; I'm just taking into account
the past and current reasoning behind KConfig, and the code that's using it.
But I think that having to get to a group (explicitely, not via KConfig itself)
before reading/writing is actually quite consistent.

> > > > 3) let's not be confusing about how to use KConfig. There should be
> > > > one way, and it should work.  And that way is: KConfigGroup.
> > > > 
> > > that's no contradiction by definition. ;)
> > 
> > There is. I mean KConfigGroup, explicitely, in the code.
> > I already see all the newbie-written kde4 apps using KConfig only and 
> > thus writing everything into the root group.... ugly.
> > 
> you're making up a problem here. it's a documentation issue. 
Yeah, we all know how much people read documentation :-)
> and really: why should people stop using groups just because the code not doing it
> does not look ugly any more? 
Because the code will do it implicitely, when using KConfig::readEntry -- which is
what all people with some kde3 experience do, remember...

> and apart from that: in kde3, one could 
> have had code that simply does not call setGroup, too.
Yeah, and when you did that, you ended up in some group that was set by
some other code in kdelibs (missing a group saver) :-)
We fixed that issue with KConfigGroup, let's not reintroduce it with "you need
KConfigGroup to read/write, oh but in fact you don't really need it, KConfig
has that API too"... A rather confusing message for developers.
 
> > I thought you said "too much porting effort, it will remain, but deprecated"?
> >
> i said that about KConfigGroup::changeGroup(). KConfig::setGroup() is
> virtually unused these days (and not to influence reads/writes anyway,
> as this currently works only via KConfigGroup, obviously).

And here again, when you say unused, you mean in SVN.
As long as the method exists, kde3 code (out of SVN) that will be ported 
to kde4 in the future, will compile, and will work wrongly. That is a huge problem.

> > Viewing config as a tree is a good reason for having a root group
> > indeed, but it is not a reason for KConfig being the root group
> > itself.
> > 
> it is. if you don't do it, you introduce special cases for things that
> are no special cases in fact.

There is no special case in the sentence "you need a group to be able to read and write".

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).