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