Registering Plugin Jobs with Shell's Run Controller

Andreas Pakulat apaku at gmx.de
Wed Dec 14 08:09:42 UTC 2011


On 13.12.11 23:08:17, David Narvaez wrote:
> On Tue, Dec 13, 2011 at 6:57 AM, David Narvaez
> <david.narvaez at computer.org> wrote:
> > Hi,
> >
> > Regarding comments from Andreas on bug 284148[0] and review 103285[1],
> > I'll be working on finding plugin code that registers jobs in shell's
> > run controller and post them here to see what we will do with that.
> > What is the rule of thumb then? No code under the plugin directory can
> > register something on shell's run controller?
> >
> > David E. Narváez
> >
> > [0] http://bugs.kde.org/show_bug.cgi?id=284148
> > [1] https://git.reviewboard.kde.org/r/103285/
> 
> Just by grepping the code under the plugins directory I found 27
> references to the registerJob() method of the shell's run controller
> spread among 12 files, 7 of them related to VCS. I wonder what the
> strategy will be for these particular cases: these often are
> instantiated with a project, so they will stick around as long as the
> project is around. If so, we could add a run controller inside the VCS
> Plugin basic interface and each VCS plugin registers its jobs in its
> own controller.
> 
> On the other hand, they are also used to fetch projects. In those
> cases, they are just used to return a job which is later registered at
> the run controller (that one is a valid registration because it is not
> registered by a plugin), so that case would be covered too.
> 
> Any other consideration I'm missing? Does anybody have agree or have a
> different suggestion?

I think you misunderstood what I was trying to say. Its perfectly fine
for a plugin to register a KJob with our own KJobTracker (aka Run
Controller). What does not really make sense is registering KIO::Job's
there, since those are already tracked outside of KDevelop by KIO's own
Ui.

Andreas





More information about the KDevelop-devel mailing list