KConfigXT and kdeglobals - Linux Registry as option for 4.0 ?

Helio Chissini de Castro heliocastro at uol.com.br
Fri Sep 3 11:18:44 BST 2004


Ok, now people had oportunity to see how is made Linux Registry on Akademy, so 
i ask if be considered to an option to KDE 4 ( have plenty of time to solve 
issues if exists ).

For KDE 3.4, the CLEAN idea, even breaking compatibility, can help a lot 
packagers stay with one config type. Will be more sane to packagers create 
their defaults. And yes, i'm aware of upgrades, but i think it's possible 
handle a carefull upgrade script.


On Thursday 02 September 2004 22:23, Frans Englich wrote:
> Hello all,
> 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:
> http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binaryc
> 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 alternatives:
> 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?
> Cheers,
>   Frans

More information about the kde-core-devel mailing list