Couple things:<br><br>1) Seems that instead of pause() I should write suspend() at KJob class. What do you think ? On KIO::Jobs it is suspend (so the porting should be easier), and on slaves it is suspend too, just to be coherent with the existent code.
<br><br>Now, I think two-exclusive solutions are available for handling changing-state jobs:<br><br>a) New signals for each possible change of state:<br><br>     void paused/suspended(KJob *);<br>     void resumed(KJob *);
<br><br>    Jobs state may be changed from several points. kuiserver, the program that launched the job... so they are always notified when things happen.<br><br>b) Having the state approach that I said before. We could have some state at an enum, and each time setState is called, a signal called:
<br><br>    void stateChanged(Kjob *); or void stateModified(KJob *);<br><br>    could be emitted, so the same here: every slot is notified.<br><br>I think b) approach is somewhat better, since it drives us to a very-easy-to-expand, and to a simpler api too.
<br><br>If we get to approach b) some things should be re-thinked. Do you think result(KJob*) is necessary if we go that way (b) ?<br><br>Waiting for your comments.<br><br>Bye,<br>Rafael Fernández López.<br><br><br>