[RFC] KConfig API stuff

[Andreas Pakulat]

On 21.10.07 17:08:34, Oswald Buddenhagen wrote:
> moin,
> 
> as you probably know, puthuhn (bernhard loos) and me are fixing KConfig.
> while i'm pretty confident that nobody cares for the backend stuff we
> are doing, ;) there are also some API changes in the works.
> it's "a bit" late in the release process, so we made sure to get a
> preliminary OK from allen in advance.
> the additional effort for people not involved should be almost zero, as
> we do the complete porting - and this time you can expect quality work -
> after all, *i* am on it. ;)
> however, as this grows into unexpected dimensions, i'd like to discuss
> the changes in detail before we pursue this any further:
> 
> - kill kconfigbase, make kconfig inherit kconfiggroup.
>   - rationale: it is The Right Thing To Do (TM).

Hmm, I have to say I don't understand that. I agree with Thomas here
that KConfig is rather an unordered list of KConfigGroup's than itself a
KConfigGroup.

> - renames in kconfiggroup: name to groupName, exists to groupExists,
>   rename in kconfig: name to configName
>   - rationale: clearly necessary with the changed hierarchy. does it
>     make sense without it?

If the hierarchy changes this is fine yes, but if it doesn't I think it
doesn't make sense to change them and would only introduce extra porting
effort.

> - remove kconfiggroup::sync
>   - rationale: the api suggests a granularity that is simply not given.
>     cg.config().sync() is the proper call.
>   - problems:
>     - quite some users. manageable, though.
>     - more verbose code. do we want it?
>   => ?

IMHO: A little more verbosity in code is better, especially if the
porting is not too much work.

> - move kconfiggroup::setReadDefaults to kconfig
>   - rationale: all users (mostly kconfigskeleton derivatives) deal with the
>     entire file at once anyway
>   - problem: it's ugly and cries "i'm not reentrant"
>   => no-go?

Don't really know about the removing, thouh I think a rename would be
good, something like setReadSystemDefaults. Its not obvious from the
function name that Defaults == SystemDefaults. Of course only if really
just kdelibs code uses this, else I guess a new setReadSystemDefaults()
along with deprecation of the setReadDefaults method would be ok as
well.

> - remove the separator argument from {read,write}Entry for lists
>   - rationale: the separator is a backend internal detail. with some
>     backends, it might be plain unchangeable.
>   - problems: none
>   - non-problems:
>     - there are some abuses of the separator argument and some plain
>       pointless uses. easily fixable.
>     - it was suggested that this would imply changing the kde-wide
>       separator back to the semicolon, as .desktop files use the
>       semicolon and kdesktopfile is in fact a kconfig, so we'd have no
>       way to get it right otherwise.
>       in fact, we might provide an api (possibly accessible by
>       kdesktopfile only) to put the entire file into .desktop mode -
>       that makes most sense anyway.

So are you saying a normal KConfig would use "," as separator and
KDesktopFile would use ";"? I guess the reason is the amount of
kconfig-file-updates needed, if so I agree.

> the code can be found under branches/work/kconfig_new_take2/ .
> note that not all changes are implemented yet and nothing beyond kdelibs
> is guaranteed to compile.

Whats your time plan for this? If this is going to happen I think the
platform release should be moved by a few weeks.

Andreas

-- 
Your lucky number has been disconnected.