Review of output view interface

[Andreas Pakulat]

On 27.05.07 21:18:00, Matt Rogers wrote:
> On Sunday 27 May 2007 21:00, Andreas Pakulat wrote:
> > On 27.05.07 20:41:32, Matt Rogers wrote:
> > > - 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. 

Well, I had another thought or two just before sleeping yesterday. Not
everything is "finished" here, but how about a special model class that
has an additional method or slot for activating an item (or provide a
selectionmodel for that??) so the plugin can give iouputview a model and
the view can connect the activated signal to the slot of the model. That
way we don't need a custom view for just providing some extra
functionality (doing something when highlighted lines are clicked) that
is re-created by each plugin. I'm just not sure wether we should
subclass QAbstractItemModel or QStandardItemModel for our custom model.
We can of course also just emit a signal from the outputview each time
an index in a model is clicked, with a signature like this:

activated(const QModelIndex& index, const QString& id);

And the plugin can connect itself to that and do whatever it wants if
its an id it knows about and the index is valid.

Last thing: For executing I think a somewhat extended ProcLineMaker
should be fine. I don't think we need much filtering there, I think its
rather treating certain lines specially. At least I can't see filtering
or sorting in the way of QSortFilterProxyModel to be done here.

> 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?

ProcLineMaker emits the lines as stringlist, but it doesn't emit all
lines if the last line doesn't contain a \n. It emits such unfinished
lines only if the other outputchannel gets some output. So for example
if the process ouputs these two strings:

stdout:
"Compiling foo.c
gcc -o foo.o foo.c"
stderr:
"Warning: missing newline character at end of file
"

Then you'd first get a signal with "Compiling foo.c", after that the
stderr output is signalled to proclinemaker and it outputs the rest of
the stdout output so you'd get 2 signals, one with the rest of stdout
and another one with the warning right after that.

Andreas

-- 
Don't read everything you believe.