<div><div>Hi Matthias and all,<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> ## kdelibs.diff ##<br><br>I'm not so happy about adding the init method. For this particular case I'd

<br>really favor to add the line<br>QTimer::singleShot(0, this, SLOT(changed()));<br>to the constructor. What is "conditional to the system" about that?</blockquote><div><br>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. 

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Do you see other use cases for the init method than the one you described?</blockquote>

<div><br>That one only. I fail to see others. Probably there are more, but certainly they don't come to my mind :)<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

call from their ctor.</blockquote><div> 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.

<br><br>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. </div></div> Bye and thanks for answering, Rafael Fernández López.