Suggesting another little improvement for KJob class

Kevin Ottens ervin at kde.org
Thu Feb 8 08:32:24 GMT 2007


Le jeudi 8 février 2007 01:12, Rafael Fernández López a écrit :
> 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.

In such case maybe it'd be wise to make KJob::Pausable become 
KJob::Suspendable too. :-)

> 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 go with states (I'm still unsure it's really needed, we really only have 
suspend to manage right now, I see nothing else useful for now), b) 
definitely looks better to me.

I think we could be nice to our app developers and give the new state in the 
signal:
void stateChanged(Kjob *, State);

This way for simple states no further querying of the job is required.

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

Yes, I'd keep result in any cases. As an app developer, you very often 
(always?) want to be notified when the job ends. But it's less likely that 
you want to be notified about every state change. So keeping result() is a 
good trade-off IMO.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070208/5bdcca72/attachment.sig>


More information about the kde-core-devel mailing list