Disabling KCMs in runtime

[Frans Englich]

A significant amount of KCMs are irrelevant for a lot of setups and it should 
be detected runtime whether they should be shown or not. For example, 
xinerama, laptop KCMs and perhaps certain KCMs for applications 
configuration.

One way to implement this while not having an unacceptable performance penalty 
is AFAICT to have a boolean "X-KDE-Conditional-Loading" desktop directive 
which determines whether a module needs to test if it should be shown or not. 
If it should be tested, that is X-KDE-Conditional-Loading=true, a 'bool 
test_modulename()' is run when the module should be loaded, similar to the 
init_* or create_* functions. This function can then test for presence of 
software/hardware and `return true;` if it should be shown.

Attached patch adds to KCModuleLoader a static function called probeModule() 
which first checks the desktop directive, then continues with loading the 
library and finally runs the function, if it gets that far.

I've ported KCMultiDialog and KCModuleContainer - "it works for me".

What about speed?
Worst case possible is Kontact with its ~20 KCMs, KControl is not that bad 
either, about 10 KCMs needs to be checked at a time.
This is how the code path is extended:
1) For each KCM to be shown a service lookup is 
needed(X-KDE-Conditional-Loading). I don't think this has any noticeable 
performance hit. (Someone with hard facts?)

2) If a module is to be tested, its library need to be loaded and then the 
function run. If the module should be shown, the overhead wasn't that big 
since the library needed to be loaded anyway. If the module is Not to be 
shown it corresponds to loading one extra KCM. These figures has an time 
offset of the KCMs testing time. Assuming the KCM needs testing - quite rare.

But I probably discuss this in excess - considering how this will be used in 
the practice or if even heavier than that, I think it is cool. I've tried 
Kontact on my dual SMP Athlon MP 1800+ with hot disc cache and I can't notice 
anything, although it only tests the service lookup part.

Comments?


Cheers,

		Frans 

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcmoduleloader.diff
Type: text/x-diff
Size: 4295 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040320/035c21da/attachment.diff>