Rework of the outputview interface

[dukju ahn]

2007/6/9, Andreas Pakulat <apaku at gmx.de>:
> On 09.06.07 09:28:20, dukju ahn wrote:
> > The outputview is good but I have some comments on ExecuteCommand
> >
> > 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.