KConfig vs. QSettings (was Re: Porting problems with KMainWindow::readProperties())

[Branan Riley]

I like that. It's clean, clear, and won't require much, if any, change
to existing apps. I have a couple of ideas for extending KConfig as
well, and before I start hacking at the code, I'd like to make sure
others are interested, or if the ideas are even plausible. Both are
dependent on having subgroups, and the second depends on the first
(for some uses).

The ability to change the root to be a subgroup. For example, suppose you have:
[MyConfigGroup]
key1=value1
MySubGroup\Key1=value2
MyOtherSubGroup\key1=value3

Now, here's where it gets fun. What if, rather than treating sub
groups as such, you could treat them as alternate configurations? The
user gets a list (probably through a combo box) of the configurations,
and can selct which one. Example:
<Any built-in configurations>
MySubGroup
MyOtherSubGroup
Custom

When Custom is selected, it just uses the normal root, andreading key1
gets value1. Now, suppose you could tell KConfig to alias MySubGroup
to the root. Now, when you read key1, you would get value2 instead.

The other feature is more complex. Dynamic file-merging is the best
description I can think of. You load another config file, but add all
the keys in that file to a subgroup. You could then load a custom
config file, merge it with the main config, and have all the keys
prepended with a prefix. Suppose you have:
<myapprc>
[MyGroup]
key1=value1

<MyOtherConfigFile>
[MyGroup]
key1=value2

You tell KConfig to load MyOtherConfigFile, and prefix with MyPrefix.
Internally, you get:
[MyGroup]
key1=value1
MyPrefix\key1=value2

Combined with the first idea, you would be able to easily manage
multiple configuration files through the same kcfg_elementName widgets
that could be used for a single configuration file.

Questions or comments? If there's a lot of support for the idea, I
might even start defining the API before I start coding, so there's
concensus on how everything should work.

Branan