Suggesting another little improvement for KJob class

[Rafael Fernández López]

Couple things:

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.

Now, I think two-exclusive solutions are available for handling
changing-state jobs:

a) New signals for each possible change of state:

     void paused/suspended(KJob *);
     void resumed(KJob *);

    Jobs state may be changed from several points. kuiserver, the program
that launched the job... so they are always notified when things happen.

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:

    void stateChanged(Kjob *); or void stateModified(KJob *);

    could be emitted, so the same here: every slot is notified.

I think b) approach is somewhat better, since it drives us to a
very-easy-to-expand, and to a simpler api too.

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) ?

Waiting for your comments.

Bye,
Rafael Fernández López.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070208/588d29db/attachment.htm>