Refactoring KCM technology

[Frans Englich]

With the new KCModuleProxy[1] one of the effects is kcmshell can be 
independent from KControl and kcmshell's code size can be reduced. Attached 
main.cpp(using the kdebase/kcontrol/kcontrol/kcmshell.h) is a new version of 
kcmshell which drop its (custom) KCDialog and uses KCMultiDialog instead, 
combined with various other cleanups.

I would like to move kcmshell to kdelibs because:

1) It is KDE (technology) infrastructure.

2) KCModuleProxy uses it for running root KCMs. KCModuleProxy recover but 
obviously doesn't run root KCMs if kcmshell is not available. Rephrased: If a 
user only have kdelibs(and doesn't contain kcmshell) and runs an application 
which tries to load a root KCM it won't work. No code does this currently but 
k3b will, most likely.


This does not come without complications however. kdesu is also needed in the 
setup described above which in turn suggests kdesu also is moved to kdelibs. 
I think moving kdesu also make sense with the same motivation as above - it 
is reasonable to assume 3rd party KDE applications need (kde)su capability, 
without having to install kdebase.

I would also like to move kcminit to toplevel kdebase. After that the various 
stuff in kdebase/kcontrol/kcontrol/ is sorted out and separated. Afterall, 
they are not related or belongs together technically, they all just happen to 
involve KCMs(and is bunched together because of historic reasons - KCMs was 
once only for kcontrol, AFAICT).


Comments?


			Frans


1.
http://lists.kde.org/?l=kde-core-devel&m=107931274802076&w=2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp
Type: text/x-c++src
Size: 7684 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040319/cd034e79/attachment.cpp>