KConfig nested groups

[Aaron J. Seigo]

On March 2, 2007, Paolo Capriotti wrote:
> Here's a patch implementing nested groups in KConfig. It seems to
> work, but who knows what I might have broken :)

some thoughts:

aIt.key().mKey.startsWith(prefix) looks slow, and is really a backend detail 
related to how it is stored on disk. e.g. backends that can actually store 
hierarchies of data (e.g. ldap) will not follow this pattern.

perhaps it makes more sense to actually store the entries as a tree in kconfig 
and leave it up to the backend to populate that tree? that way getting the 
entrymap for a group is simply descending the tree once and returning all the 
non-default, non-deleted entries.

the downside to that and having each key store the group in an INI file would 
be performance: the INI backend would need to parse -every key- to see if it 
belongs to a sub-group or not. not to mention the additional disk space 
required to store the group prefix over and over again in the key name. 
perhaps it would therefore make more sense to have the subgroupings in the 
[GroupName] rather than the keys for the INI case... e.g. instead of:

[Group]
SubGroup\\Key=foo
SubGroup\\Key\\Bar=bar
Key=baz

there'd be:

[Group]
Key=baz

[Group//SubGroup]
Key=foo

[Group//SubGroup//Key]
Bar=bar

this also reads easier to my eyes when looking at the INI file.

i'm also a little, but not much ;), concerned that the 'magic' separator 
of '\\' could appear in a legitimate key somewhere. i don't see any such keys 
in my configs, but is perhaps something for us to be doubly sure about.

the kconfigdata.h changes look good... =)

semi-unrelated: i wonder if the entryMap methods should be taking a QByteArray 
rather than a QString as the group parameter. the group names are stored as 
QByteArrays in KEntryKey anyways.

also, please follow the kdelibs coding style:

	http://techbase.kde.org/Policies/Kdelibs_Coding_Style


-- 
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/20070302/6898eb52/attachment.sig>