Need a general point of view about jobs

Rafael Fernández López ereslibre at gmail.com
Thu Jan 25 22:15:38 GMT 2007


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;

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.

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:

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.


More information about the kde-core-devel mailing list