Review of output view interface

[dukju ahn]

2007/5/28, Andreas Pakulat <apaku at gmx.de>:
> 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.

I doubt the idea that each plugin provides their model.
Just providing model isn't sufficient to display custom contents.
Think about the
case when some plugin needs special view, say "CircularView",

Most importantly
I think OutputView doesn't need to be that flexible. After all, outputview is
small utility class to display simple string output. If some plugin needs
complex and flexible unique output, it may want to treat it themselves, rather
than using outputview.

Most of the plugins may don't want to create and manage the custom model
just to print out simple strings or clickable items. That's the reason
of existance
of OutputView. If things get complicated, plugins will do their own.