Rework of the outputview interface

[dukju ahn]

2007/6/8, Andreas Pakulat <apaku at gmx.de>:
> Hi,
>
> as Matt suggested some time ago, I reworked the outputview to more
> closely follow the MVC pattern.
>
> The outputview now has a much simpler interface, registering a new view
> with title, setting a model for that view and emitting a signal whenever
> an index in the view is activated.
>
> Also this adds a really simple OutputModel for convience, it just
> provides 2 slots to connect to ProcessLineMaker or the new
> ExecuteCommand class on top of a QStandardItemModel. This is not meant
> to get extended, unless we find that various outputview-users do the
> same thing in their custom models. Really just convenience (thats also
> why it lacks api docs, I will add these before commit of course)
>
> Last but not least there's the new ExecuteCommand class, it provides
> simplified signals on top of QProcess to make it easier to execute
> commands for the outputview. I've put it into util because it can be
> used for other things as well (if you only need the output and
> failed/completed signal). For more complex needs QProcess (or the
> proposed KProcess from Oswald) can be used.

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.

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.