KConfigGroup (Re: KDE/kdelibs/khtml)

David Faure faure at kde.org
Sat Feb 10 23:24:17 GMT 2007


On Sunday 11 February 2007, Aaron J. Seigo wrote:
> On February 10, 2007, David Faure wrote:
> > On Friday 09 February 2007, Aaron J. Seigo wrote:
> > >  - a method in KConfig that returns a KConfigGroup object
> >
> > Does this change anything?
> 
> for me it comes down to which makes an easier to understand API: a kconfig 
> object that provides access to groups, or a kconfig object you need to use 
> with another class to get at groups. the former is nearly self-documenting, 
> the latter requires a bit of a tutorial.

OK.

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

> > >  - providing a KConfigGroup(const QString& config, const QString& group)
> > > which creates an internal KConfig as a shortcut for this common idiom:
> >
> > I am strongly against this. People will write code like
> > KConfigGroup group1("myconfigrc","group1");
> > group1.writeEntry(..);
> > KConfigGroup group2("myconfigrc","group2");
> > group2.writeEntry(..);
> > ... which will lead to myconfigrc being parsed twice. Very slow.
> 
> sorry, my assumption was that we'd be using a KSharedConfigPtr internally so 
> this wouldn't be an issue.
Ah, right. Hmm. OK then, although I dislike the config-filename duplication in
the above code. In fact giving a config file name should really be the rare case
(of having data split out in several config files; like e.g. kmail should do :) ).
KGlobal::config() or KComponentData::config() should be used in most places.
Ah well, at least passing a filename won't have an effect on performance anymore
thanks to ksharedconfig.

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