REMINDER: Final review of VCS interfaces

[Andreas Pakulat]

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)

Andreas

-- 
That secret you've been guarding, isn't.