From kde-core-devel  Fri Sep 03 01:23:14 2004
From: Frans Englich <frans.englich () telia ! com>
Date: Fri, 03 Sep 2004 01:23:14 +0000
To: kde-core-devel
Subject: KConfigXT and kdeglobals
Message-Id: <200409030123.15043.frans.englich () telia ! com>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109418990303192


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-binarycompatibility.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