[PATCHES] KCModule changes and kutils fixes

[Rafael Fernández López]

Hi Matthias and all,


> ## kdelibs.diff ##
>
> I'm not so happy about adding the init method. For this particular case
> I'd
> really favor to add the line
> QTimer::singleShot(0, this, SLOT(changed()));
> to the constructor. What is "conditional to the system" about that?


With 0 it didn't work for me. With 10 or 100 it did. That makes me nervous.
I think is cleaner using a method that we know how it will work. After all
that's even better for debugging too in case of problems.

Do you see other use cases for the init method than the one you described?


That one only. I fail to see others. Probably there are more, but certainly
they don't come to my mind :)

Another approach would be to call load() from KCModuleProxy in the place
> where
> you call init(). Actually that's how I'd like the KCModule interface to
> work,
> but that's a pain to fix in all the KCMs where you have to remove the
> load()
> call from their ctor.


That  won't work. I really agree of calling load() where it is loaded
instead of the constructor of each module. That makes sense and sounded
strange to me when I saw each module had to call load() individually.

Anyway, load() won't do the trick. The situation was: we have a plugin that
*needs* to inform about its situation when the button "OK" is clicked on its
configuration dialog, it doesn't matter if something was changed on its
configuration dialog or not. load() in all cases what will do is emit
changed(false). In this case:

void .....::init()
{
    emit changed(true);
}

I really think this is quite better than QTimer::singleShot. If you think
the init() method shouldn't be added I can change it to a QTimer::singleShot
(though I don't support that decision). What  time should I put on the call
then if I use singleShot ? 0 won't work for sure on some computers (at least
on mine it doesn't). A longer time it will (as I said, 10 or 100).

What makes me nervous about QTimer::singleShot is why we need to relay on
time for making a call to a method. We never know to where the main part of
the program (the caller) have reached. We have no control of what's going
on. From all perspectives I really think is more rock-solid calling to
methods in a known order and in known situations.

Anyway, as I said, if you guys think singleShot is better, I just will
change the thing to it.


Bye and thanks for answering,
Rafael Fernández López.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070825/159bb939/attachment.htm>