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