KConfigGroup (Re: KDE/kdelibs/khtml)

David Faure faure at kde.org
Sun Feb 11 12:52:59 GMT 2007


On Sunday 11 February 2007, Stephan Kulow wrote:
> Am Sonntag, 11. Februar 2007 12:48 schrieb Stephan Kulow:
> > > > on a related note, are we going to hide readEntry() and writeEntry as
> > > > well and move them to KConfigGroup? if not, what does a KConfig object
> > > > with no ability to directly set the group do precisely? i would guess
> > > > it writes to [General], but again it's just a very odd API now.
> > >
> > > Makes sense (the removing or at least deprecation of all those methods
> > > together). Not the writing to [General] - that's a habit we should drop
> > > btw since kdeglobals provides a [General] group too so kiosk restrictions
> > > on it affect the app's General group too; and vice-versa iirc. An
> > > unfortunate name clash.
> >
> > I think I'm going to test if the kde4_kconfig branch is any alive and see
> > how much effort it is porting :)
> >
> 
> OK, I did some experiments and not hiding readEntry and co just asks for 
> porting errors of code like
> 
>   config->setGroup( "Group");
>   config->readEntry("Key");
> 
> to 
>   KConfigGroup cg(config, "Group");
>   config->readEntry("Key")
> 
> this will compile fine, but won't work.

This already happens - it's the kmail account-saving bug whose fix I'll be committing tomorrow.

> But hiding readEntry and co is a bit problematic as KConfigGroup inherits from 
> KConfigBase. This will only work if we _move_ the symbols to KConfigGroup, 
> which I'm a bit scared of.

Just make them protected in kconfigbase?

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




More information about the kde-core-devel mailing list