[RFC] KConfig API stuff

[David Faure]

On Monday 22 October 2007, Oswald Buddenhagen wrote:
> On Mon, Oct 22, 2007 at 02:53:52PM +0200, David Faure wrote:
> > But I think that having to get to a group (explicitely, not via
> > KConfig itself) before reading/writing is actually quite consistent.
> > 
> actually, it is not. to be consistent, you'd have to write it like this:
> 
> KConfig().rootGroup();
> KConfig().rootGroup().group("group1");
> KConfig().rootGroup().group("group1").group("gorup2");
> 
> really, trivial tree theory ...

Yeah, but which doesn't take into account KConfig's history.
Consider KConfig::group("group1") as a shortcut for rootGroup().group("group1").
We have accessors for level1 items, so what? It's still the most common (well, the only right now)
use of KConfig.

QTreeWidget is very similar, with its topLevelItem(n) and its special root item
(although QTreeWidget gets it wrong because parent() of a toplevel item is 0
and not the root item, which leads to lots of trouble when writing generic code;
but KConfig can avoid that mistake easily).

> > > > 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 :-)
> >
> well, one has to read some of the docs anyway to get started. or read
> some examples, which pretty surely will do the right thing.

Wanna bet that nobody will get it wrong?

> > > > 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.
> > 
> no, it's not, because setGroup() won't exist. the old code will simply
> not compile, just like it does now. this also makes the "kde3
> experience" argument fall flat.

Take this kde3 code:
config.setGroup("foo");
config.writeEntry("bar",42);

Upon getting a compilation error with setGroup and a hint about KConfigGroup in the documentation,
the person doing kde3->kde4 porting will write
KConfigGroup cg(&config,"foo");
config.writeEntry("bar",42);

Why touch the second line, it compiles fine as it is now.
Yeah, except that it does the wrong thing, but the person doing the porting, being new 
to the kde4 api, won't know that. Call me conservative, but in the end what matters
is less bug for our users; and keeping KConfig::writeEntry() but with a different semantic
is really opening the door for such porting bugs.
You mentionned that this was kde5 material - in that case it's completely different;
there won't be such kde3 code around to be ported to that future KConfig API directly,
so the problem won't happen; kde4 will have cleaned up the code meanwhile.

> > > > 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".
> > 
> there is a special case in the sentence "you need as many groups as
> deeply as your hierarchy is nested, but wait, you still need a group
> when you want to access the root level".

Yes, so don't phrase it like that :-)

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