Rework of the outputview interface

[Andreas Pakulat]

On 09.06.07 09:28:20, dukju ahn wrote:
> 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.

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.

Andreas

-- 
Try to get all of your posthumous medals in advance.