Suggesting another little improvement for KJob class

Ricard Marxer Piñón rmarxer at iua.upf.edu
Wed Feb 7 20:33:50 GMT 2007


Ricard Marxer Piñón wrote:
> Rafael Fernández López wrote:
>> Hi all,
>>
>> 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.
>>
>> 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 agree with this approach.
> but maybe a more elegant way to do it, would be having several generic 
> properties, like:
> hasStarted()
> isPaused()
> hasFinished()
> errorValue()
>
> This way you can acheive all the states without the enum.
>
> What do the others think?
Forgot to mention that for the action of pause()/resume() I would propose:
togglePause()

This would return an exception and don't send the action if the job 
doesn't have that capability.

>>
>>
>> Bye and thanks,
>> Rafael Fernández López. 
>





More information about the kde-core-devel mailing list