Suggesting another little improvement for KJob class

[Kevin Ottens]

Le mercredi 7 février 2007 19:57, Rafael Fernández López a écrit :
> I came out with a problem with kuiserver. We have capabilities, and think
> about the capability "Pausable". When we receive a signal of which action
> was triggered, we will get KJob::Pausable as actionId. When you click on
> the "Pause" button, it should go to "Resume", and then, the problem comes,
> how to do in an elegant way to retrieve a different KJob::Pausable than
> before... I mean, it is not cute at all having KJob::Pausable,
> KJob::Resumeable (i don't even know if it is said this way). If a job can
> be paused, then it can be resumed.

Wouldn't it be simply solved by having suspend(), resume() and toggleSuspend() 
on KJob?

> So I came up with an idea, and I don't really know if is the best, but it
> can give us a more interesting approach to jobs in general. I suggest
> having new methods in KJob class:
>
> void setState(State state);
> State state() const;
>
> Where State could be an enum, for example with some of this: "InProgress,
> Paused, Cancelled, Failed". I don't know if more or them may be
> interesting.
>
> What do you think ?

I wonder how useful it could be if your current issue is solved by a 
togglePause(). Anyone see where we would want to query the state of a job? 
AFAIK it's a need we don't have.

I think that apart from isSuspended(), available in KIO::Job for now, nothing 
else is required.

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/46435f1e/attachment.sig>