REMINDER: Final review of VCS interfaces

Andreas Pakulat apaku at gmx.de
Mon May 28 01:53:42 UTC 2007


On 27.05.07 20:34:08, Matt Rogers wrote:
> On Sunday 27 May 2007 16:29, Andreas Pakulat wrote:
> > On 27.05.07 09:01:44, Matt Rogers wrote:
> > > On May 27, 2007, at 4:48 AM, Andreas Pakulat wrote:
> > > > On 27.05.07 11:06:21, Robert Gruber wrote:
> > > >> I'm still not sure about returning VcsJob anyways. For example in
> > > >> cvs plugin I'm using my own CvsJob class which is derived from
> > > >> KJob and therefore already provides all that stuff from VcsJob. So
> > > >> why don't we just return a KJob pointer? Or maybe derive VcsJob
> > > >> from KJob, which will make the start and cancel slots and the
> > > >> signals needless as they are already provided by KJob.
> > > >
> > > > Because KJob doesn't provide an API that is usable. VcsJob should
> > > > either
> > > > be a pure interface which you inherit from additionally to KJob or it
> > > > should be a KJob subclass. I'm not sure which approach is better,
> > > > didn't
> > > > really look into that yet (but I'm guessing the second one)
> > >
> > > How is it that KJob does not provide an API that's usable considering
> > > there are plenty of places it's used throughout KDE? We need to
> > > derive VcsJob from KJob.
> >
> > I knew somebody would ask right after I sent the mail :) The thing is
> > that KJob only provides means to start/kill/resume the job. VcsJob adds
> > a few things on top of that (type, results, common finished signal)
> 
> That still doesn't stop us from deriving from KJob, in fact, it's the perfect 
> case for building on top of it. Am I right, or do I miss something?

Well, its not much that VcsJob can do itself, basically each plugin has
to create its own vcsjob subclass and do a proper implementation. All
that VcsJob can do is implement cancel() and kall KJob::kill() and then
plugins *job subclass would implement doKill(). So I'm not sure having
that one method implemented justifies a KJob subclass.

Andreas

-- 
You may be gone tomorrow, but that doesn't mean that you weren't here today.




More information about the KDevelop-devel mailing list