KDE/kdelibs/khtml

[Aaron J. Seigo]

On February 9, 2007, Stephan Kulow wrote:
> Is there any reason to stick with setGroup (being public)?

it's easy and obvious. there's a lot of code where a kconfig object is 
created, the group is set a few times, a few keys are read/written and the 
kconfig object is deleted. setGroup() is pretty natural there.

without setGroup, it would mean creating a number of KConfigGroup objects. 
basically it means a lot of porting effort and a harder to understand API 
since the instructions would be "create a KConfig object, then for each group 
you wish to access create a KConfigGroup object". not quite as 'obvious' 
imho.

some things that could help make it as easy as possible:

 - a method in KConfig that returns a KConfigGroup object
 - providing a KConfigGroup(const QString& config, const QString& group) which 
creates an internal KConfig as a shortcut for this common idiom:

	KConfig config("foo");
	KConfigGroup group(&config, "bar");

perhaps even KConfigGroup(const QString& group) to shortcut this idiom:

	KConfigGroup group(KGlobal::config(), "bar");

IOW, if we remove KConfig::setGroup() from the public API, we will want to 
make KConfigGroup more convenient to get to and use. which is thankfully 
pretty trivial to do.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070209/f6e1dfc8/attachment.sig>