[RFC] KConfig API stuff

[Oswald Buddenhagen]

based on the remaining response this is most probably kde5 material
anyway, but let's bring it to a conclusion nonetheless:

On Mon, Oct 22, 2007 at 02:08:59PM +0200, David Faure wrote:
> On Monday 22 October 2007, Oswald Buddenhagen wrote:
> > On Mon, Oct 22, 2007 at 11:17:58AM +0200, David Faure wrote:
> > > On Sunday 21 October 2007, Oswald Buddenhagen wrote:
> > > > make kconfig inherit kconfiggroup.
> > > 
> > > I object to KConfig inheriting KConfigGroup:
> > > 
> > > 1) the entries in the root group aren't that important, using them is
> > > kind of bad practice for actual KDE config files, except special cases
> > > (kioslaverc).
> > >
> > that doesn't mean that the api needs to be intentionally ugly. ugly apis
> > don't prevent people from doing ugly things, they just make the code
> > look ugly, including the one that uses the api legitimately.
> 
> 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?

> > > 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. and really:
why should people stop using groups just because the code not doing it
does not look ugly any more? and apart from that: in kde3, one could
have had code that simply does not call setGroup, too.

> > > 2) the porting from kde3 will be horrible. Every single kde3 app out
> > > there, whose code does config.setGroup("foo");
> > > config.writeEntry("bar","42"), will end up writing into the root group
> > > without the author wanting that at all.
> > > 
> > after the hierarchy change setGroup() wouldn't make any sense and
> > therefore must be removed anyway, so this is a non-issue.
> 
> 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).

> Therefore it will compile, but will NOT work as expected.
> *That* is ugly API.
> 
... consequently non-issue.

> 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.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.