Need a general point of view about jobs

[Ricard Marxer Piñón]

Rafael Fernández López wrote:
> Hi all guys,
>
> At this time I'm re-thinking all the job subsystem that right now
> exist on KDE 4. Suppose the user create a new job class that inherits
> KJob. So, right now we are at this point:
>
> * (Fact) To notify the kuiserver it is needed to call somewhere
> Observer::self()->newJob(theJob,.....);, or maybe yes, on the own
> constructor, Observer::self()->newJob(this,.....);.
>
> * (Need) We have no current state for jobs actions. That is going to
> be fixed, likely (I talked to dfaure and ervin and they both agree)
> adding some kind of new method to KJob class:
>
> void setCapabilities(Capabilities capabilities);
> Capabilities capabilities() const;
This sounds really good.
>
> for example, to know if a job is pausable, stoppable or that kind of 
> things.
>
> * (Suggestion) Currently, we don't provide a "native" way of provide
> some type of queue to jobs. It would be really nice if we could
> provide jobs some kind of mechanism.
I guess with the states it will become much easier.  Though there's 
still inform the observer about a tree of jobs (the tree structure used 
to indicate dependencies on endings of jobs).  This makes me think that 
we should make a difference between jobs finished unexpectedly (with 
errors) or normally (without errors).
>
> Okay, to solve the (Fact), I propose creating some kind of new job
> class (outside from kdecore), that inherits KJob, and that is the one
> that is supposed to be inherited by jobs that want to be shown on the
> uiserver. For example:
I don't think it's the best idea to make an observable job.  I think the 
best would be to inherit or instantiate directly (if no extra 
functionality is required) a KJob.  Then call a method on it (for 
example myJob->publish()) which will make it observable.

When publish() is called the KJob could handle everything transparently 
with the Observer.  And this could mean that the developer doesn't even 
need to know about the Observer. (No need for the developer to worry 
about jobId etc. if they can use a KJob object)

As a side effect of this approach.  The developer will be attracted to 
use KJob even if there's no need of publishing the job, just as a common 
way for all KDE apps of managing progresses of jobs.  It would be nice 
to have in kdeui a KJobWidget which will be the default job user 
interface, this being independent from the Observer.

>
> public ObservableJob : public KJob
> {
>  ...
>  Q_SIGNALS:
>    void actionPerformed(int actionId);
>  ...
> };
>
> or
>
> public ObservableJob : public KJob
> {
>  ...
>  Q_SLOTS:
>    virtual void actionPerformed(int actionId) = 0;
>  ...
> };
>
> or
>
> public ObservableJob : public KJob
> {
>  ...
>  Q_SLOTS:
>    virtual void actionPerformed(int actionId);
>  ...
> };
>
> So in the first class template, we could provide the job the power to
> connect that signal wherever the coder wants (for example, some slot
> on the main program). The others, are pretty good organized, since all
> that is related to jobs, is done on the job itself, not outside.
>
> That is the main reason, making the new class that the coder writes
> (inheriting ObservableJob) more organized, since no code related to
> the job goes "outside" of that class, and that will end up on a very
> more organized code at the end.
>
> If agreed, the question is: where could we put this new class ?
>
> Bye and thank you,
> Rafael Fernández López.