KConfigXT and kdeglobals
frans.englich at telia.com
Fri Sep 3 02:23:14 BST 2004
For some time, KConfigXT files for kdeglobals have resided in kdelibs/kutils,
and I thought it could be an idea to see what to do with them now, looking
forward to 3.4/4.0. It have about 200 entries, which I think is the major
ones, but they need tighter data types(proper enums etc.), which probably is
best done when the actual code is converted(how convenient..).
What should we do with it? I think having it as a dynamic library, kutils,
would be suitable. One dilemma that brings is that binary compatability is
dependent on the XML file and the compiler that generates the code. I guess
that's no bigger problem but it requires a watchful eye. A KConfigXT section
on this topic in:
would be useful.
Another issue is KConfigXT makes configuration options more central and even
user visible(Configuration Editor) while the current kdeglobals is a chaos of
different naming styles, (lack of) groups, and where to put what. I see two
A. Clean it. This would break compatibility, or require a big update script.
IIRC, KDE 3 broke compatibility, but we should of course avoid it. Cleaning
it is preferred since we'll have it for a long time, and will gain both
developers and users(but perhaps I'm pedantic).
B. Leaving it as it is.
But I think it's useless as a starting point: It can't be compiled in
before /all/ code is upgraded, since the function signatures would change
when data types are changed.
KConfigXT&kdeglobals is messy.
Any ideas to this mess?
More information about the kde-core-devel