Rework of the outputview interface

[dukju ahn]

> > > > Before reworking, the user just queued command and forgot about process.
> > > > Then, the command runner automatically registered itself into outputview,
> > > > and redirected/filtered outputs to outputview. But now, after reworking,
> > > > the caller should manage both ExecCmd and outputview, an unnecessary
> > > > burden -- he should capture the output from executer and add to outputview
> > > > manually.
> > >
> > > ExecuteCommand has nothing to do with the outputview.
> > >
> > > > Rather, I suggest ExecuteCommand automatically register itself to outputview
> > > > and redirect outputs to it. Without this, executeCommand is not that very
> > > > useful IMHO -- because it is very thin wrapper and provides no additional
> > > > featuers.
> > >
> > > It is useful if you don't need all that extra stuff that QProcess
> > > provides, for example you don't need to know what the exitcode of a
> > > process is, just wether it suceeded or failed. The same thing for
> > > reading its output, ExecuteCommand simplifies this.
> > >
> > > And as I said ExecuteCommand has nothing to do with outputview, its just
> > > a simplifying wrapper around QProcess (and it may get some more features
> > > wrt. environment setting, if KProcess doesn't provide that). Registering
> > > a view in the outputview and providing a model that does highlighting
> > > and such things is up to the plugin that wants to present something in
> > > the outputview.
> >
> > Then, how about having such convenient  class? It's not an ExcuteCommand.
> > Why each plugin should do all that same jobs to run a simple program and
> > redirect output to outputview? In the plugins' viewpoint, running process
> > is now more harder than before. After all, we lost the existing feature.
>
> We didn't loose any feature, but we gained more control for the plugins.
> Its now easier for a plugin to provide custom highlighting,
> font-attributes and even icons for the output. Its also easier for the
> plugin to decide wether it wants to open a new outputview or just clear
> an existing one, that wasn't easily possible before.
>
> Its still relatively easy to provide a simple outputview, see the svn
> plugin (which I ported already). The QMake Builder is more complex
> because it needs to generate a separate process for each build and later
> on remove them again.

The lost feature I mentioned is about running a process and forgetting  it.
I agreed that plugin gained more control on view. I said that view is good.
The key of my argument was this -- some (utility) class which
automatically registers itself to outputview and redirect outputs to it.

I'm just suggesting one additional class.