KDE/kdevelop/lib/plugins/vcs/subversion

[Andreas Pakulat]

On 09.04.07 04:44:34, dukju ahn wrote:
> 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.

Well, thats not really needed, it has a proper API doc.

> 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.)

No, we could use ThreadWeaver. I just had a look at the API and it does
provide an API to abort the job, see ThreadWeaver::Job::requestAbort().
I'm not sure of the benefits of using ThreadWeaver though, as I don't
think we need job dependecies for svn actions and I'm not sure about
more benefits, except not having to worry about various multi-threading
issues.

> >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.

No, I think we have the right idea about KJob. The idea is to have a job
class that can be shown in a desktop-wide widget (which already exists
in kdeui) which shows currently ongoing jobs and also provides some
control over them (like pausing, aborting and so on).

> Kjob is just an interface and nothing is implemented.

And thats perfectly fine, same thing as with our interfaces.

> I am not against to using KJob. But using KJob means that
> we will wrap the existing QThread-based SubversionJobs into KJob's API.

Or ThreadWeaver::Job wrapped.

> If you keep in mind all the above things but still think KJob is useful,
> I will start to rework.

I still think it is useful. But you shoudln't start rework right away.
Wait until we have our SCM interface re-defined, so you don't have to
rework twice.

Andreas

-- 
You will reach the highest possible point in your business or profession.