Rework of the outputview interface

[Andreas Pakulat]

On 09.06.07 10:19:35, dukju ahn wrote:
> 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.

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.

Now IOutputView really is what its name suggests: A View.

Andreas

-- 
Break into jail and claim police brutality.