KDE/kdevelop/lib/plugins/vcs/subversion

[dukju ahn]

2007/4/8, Andreas Pakulat <apaku at gmx.de>:
> On 08.04.07 15:57:04, dukju ahn wrote:
> > 2007/4/8, Andreas Pakulat <apaku at gmx.de>:
> > > Especially the KJob classes would be useful for
> > > stuff that takes longer (i.e. checkout of a project) and would allow the
> > > job to be visible in the desktop-wide job-widget.
> >
> > Although we use KJob, the progress dialog should be still implemented
> > manually. KJob only emits progress percent. Unlike KIO::Job, It doesn't
> > provide progress dialog. Can anyone be more specific why we should
> > use KJob instead of QThread?
>
> Our jobs are listed in the desktop wide progress bar. So One can hide
> kdevelop on a large checkout or update and still see the progress. Apart
> from the fact that its probably easier to hook a KJob class to a
> KProgressBar (or Q*) than having a QThread do the same. Or am I mistaken
> there? (I didn't look too close at KJob)

I reviewed KJob's source code. KJOb is just an interfaces.

The KJob::start() is pure virtual and it is
excuted by the main thread. Its role is to asynchronously start new job
in a main thread loop, or in a new thread, or in a new process.
So, the important thing is that we anyway need QThread if the lengthy
jobs could be done asynchronously. (i.e. Inside KJob::start(), the
QThread::run() should be invoked.)

>There is a delegate that handles the progress showing of KJob's IIRC.
>If you want more info, you should talk to ereslibre on IRC about it.

The progress dialogs is not there. We should implement it manually.
I am worried whether the people had the wrong concept on KJob.
Kjob is just an interface and nothing is implemented.

I am not against to using KJob. But using KJob means that
we will wrap the existing QThread-based SubversionJobs into KJob's API.
If you keep in mind all the above things but still think KJob is useful,
I will start to rework.

Any comments?