From kde-core-devel  Fri Sep 03 10:18:44 2004
From: Helio Chissini de Castro <heliocastro () uol ! com ! br>
Date: Fri, 03 Sep 2004 10:18:44 +0000
To: kde-core-devel
Subject: Re: KConfigXT and kdeglobals - Linux Registry as option for 4.0 ?
Message-Id: <200409030718.44561.heliocastro () uol ! com ! br>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109420688632723

Hi..

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.

[]'s

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
>ompatibility.html
>
> 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