Review of output view interface

[Matt Rogers]

On Sunday 27 May 2007 21:00, Andreas Pakulat wrote:
> On 27.05.07 20:41:32, Matt Rogers wrote:
> > I took some time and reviewed the output view interface.
>
> Thanks for doing that.
>
> > General Questions and comments:
> >
> > - Why are we still using K3Process?
>
> See my recent mails on the commit list, last time I tested a
> QProcess/Qt4 application wasn't debuggable in KDevelop3.4. I just
> retried and now it works (wether QProcess/Qt4 changed or KProcess/KDE3
> or it was something else earlier I don't know). I just asked whats
> better to use on k-c-d, because at some point K3Process might be deleted
> and brought back as KProcess derived from QProcess. Currently the only
> real reason I see to use KProcess then is to be able to add command and
> arguments using the << operator.
>
> Unless I see a mail stating otherwise I'm going to port to QProcess
> (including proclinemaker) tomorrow evening.
>

Awesome. I'm glad it's working now. No objections from me on porting to 
QProcess.  I have other questions about proclinemaker, see below.

> > - Outputviews should only be a display mechanism. We need to come up with
> > something different to use to run external processes and capture the
> > output.
> >
> > IOutputView:
> >
> > - Remove the reference to a new tab in the API docs for the queueCommand
> > function. The view doesn't necessarily have to be created within a tab.
> > Tabs are an implementation detail of the view plugin.
> >
> > - Remove queueCommand. See above.
>
> I'll see if I can come up with an interface or class for that tomorrow.
> Now its really too late ;)
>
> In that case I guess IOutputView would just allow to create a view using
> a model, a title and possibly and id. Right? Or do you want to have a
> model for all outputviews together?
>

Right, a model, a title, and possibly and id is all that I would see us 
needing. 

My idea for the output view functionality was that a plugin would provide a 
model that contains the data for the view to display. We would have another 
interface that would provide the process execution functionality and the 
ability to capture the output. ATM, I think we should capture stdout and 
stderr separately, but I'm not totally convinced that's the way to go. Then 
the plugin responsible for providing the model to the view would also do some 
filtering on it, if needed before passing it to the view. Maybe we have the 
ability to provide a custom view too. 

I'm a bit confused about ProcLineMaker. What exactly does it do, and will we 
need it once we refactor the output view stuff a bit?
-- 
Matt