Disabling KCMs in runtime
Frans Englich
frans.englich at telia.com
Sat Mar 20 01:35:43 GMT 2004
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>
More information about the kde-core-devel
mailing list