Extending KCModuleProxy

[Frans Englich]

I've done some KCM work lately, namely trying to disentangle all the various 
helper classes, wrapper classes etc. related to using KCMs.

(all patches are from top level dir)


In kdelibs/kutils/ there's KCModuleProxy, and KControl has its own ProxyWidget 
in kdebase/KControl/. Both tries to achieve the same thing but the latter is 
the useful one. Attached kcmultidialog.diff merges both these into 
KCModuleProxy. In short, more functionality and power in kdelibs and a 
lighter KControl - the KCM technology is afterall quite generic.

This has the following advantages:

* Obsoletes quite some duplicated code and some dead code paths in KControl.

* All cases where KCMs are used behaves now consistently. For example, bug 
#72112. That means, all configure dialogs should at least be useful(but 
not as in comfortable) for 800x600 users(which use KCMs).

* All cases which uses KCModuleProxy can now load root KCMs. This further 
extends integration and flexibility, the line between root and non-root is 
blurred. For example, k3b can put its Setup2 KCM in its usual configure 
dialog(and remove it from KControl if that's not already done).

* kcmshell becomes an independent app(from KControl) and can be moved to 
kdelibs(since it is infrastructure).

* Good error reporting(which is quite confusing currently) making KCMs easier 
to code.

I would say the code is butt ugly. Doing this merge was a mess - a KCModule in 
KControl is wrapped in about 5-6(?) classes and this was squeezed into place 
with KCModuleProxy's own proxy system. BC is kept(right? :). It needs a 
thorough code review. (Waldo, Walter?). Yes, you will have to look very far 
for something uglier.

Attached kstdgui.diff adds some supporting kstdguiitems.



Ok, all that mess was necessary to create the class KCModuleContainer(attached 
kcmodulecontainer.{cpp,h}), a subclass of KCModule. It is very simple - its 
constructor(s) takes a list of modules and then builds a KCModule with tabs 
holding the requested KCMs. This is what the Monitor KCM does but 
KCModuleContainer is a little bit more elaborated - the comment text in the 
tooltip, icon on the tab, efficient saving etc.
Since it uses KCModuleProxy this one can handle root KCMs.

With it follows a macro, used for example like this:
KCMODULECONTAINER("randr, kgamma, energy, xinerama", monitor )

Accompanied by a desktop file it results principally in the same as the 
Monitor kcm which replaces kdebase/kcontrol/display/*. One small detail but 
worth to notice is that it silently drops requested KCMs which does not 
exist. For example, we can move kgamma to kdegraphics and kdebase will work 
just fine. When kdegraphics gets installed it automagically gets added to the 
Monitor KCM.

The macro expands to a factory declaration which creates a KCModuleContainer 
object.

If the module needs to do probing on construction, whether some hardware is 
available or not, this can be achieved by subclassing KCModuleContainer and 
doing addModule() manually. But this is of course not the the Right Thing - 
discussed at the end.

When this class/macro is used in the right situations it is very powerful. 
Some examples:
KCMODULECONTAINER("kcmfontinst, fonts", fonts )

Groups all font related in one kcm.

Another potential use: 

KCMODULECONTAINER("kcmkded, componentchooser, kresources", resources )

Results in a KCM, called for example "Software Components" containing 3 tabs - 
"Service Manager", "KDE Resource Configuration" and "Component Chooser".

It solves some problems quite nicely but it clearly has its limitations - the 
tab widget is not exactly the most user friendly out there as well as KCMs 
which already has tabs can not be used(but hey, that haven't hindered people 
before).
This class too makes in general the KCM technology stronger and more flexible. 
For example, one could totally rebuild the KControl layout by only editing 
KCMODULECONTAINER macros and desktop files - safe, easy and quick. Handy for 
distributors.

This also means that the KCM technology can be used in a slightly different 
way. For example: Each KCM is written in a "atomic" way - they take care of 
one thing very well. Then a KCMODULECONTAINER sews them together into one 
unit, while applications still can be very specific about what 
KCM/functionality they want to add to their configure dialog(or they could 
create their own container macro), thus skipping unnecessary options.


I haven't ported kcmshell nor KControl to the new Proxy class since I don't 
know what will be applied/rejected etc. It shouldn't need much work(kcmshell 
also needs a thorough overlook, it's rather buggy). KControl startup time 
should also increase since ConfigModule and ProxyWidget can be removed(and a 
pointer list is 
all needed instead of instantiating a ConfigModule object for each KCM). I 
estimate the speed difference would not be very big.


Further, some thoughts on KDE4 stuff:

* KCMs really need to be able to tell if they should be shown or not( that is, 
probe for hardware/software). This could be accomplished by adding to 
KCModule:
static virtual bool loadMe() { return true; }
(or similar)

Support in KCModuleContainer/KCMultiDialog would be easy, and I have some 
ideas how it would also be possible for "real", independent KCMs without 
killing KControl startup performance(hiding laptop KCMs etc)...

* All the KCM stuff starts to become quite big.. I know absolutely nothing 
about this kind of questions - would it be suiteable to have a KCM library?

* I think it could be a good idea to improve how root KCMs are handled - 
currently it is a little rough, by simply loading the whole kcm with root 
prevs. Sometimes the KCM knows better when/how what root privileges it needs. 
A KCM should be able to tell runtime about its root prevs needs.


Comments?


Cheers,

		Frans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcm.tar.gz
Type: application/x-tgz
Size: 10950 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040315/b0a667ee/attachment.bin>