Review of output view interface

[Andreas Pakulat]

On 06.06.07 13:47:46, dukju ahn wrote:
> 2007/5/28, Andreas Pakulat <apaku at gmx.de>:
> > 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.

Not each, just each plugin that wants to output some information like a
log or similar.

> Just providing model isn't sufficient to display custom contents.
> Think about the
> case when some plugin needs special view, say "CircularView",

Use case please? We're talking about output view here, that is a view
that shows the output of a certain action or program. I don't see how a
circular view could be usable for this.

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

Its not "just" a utility class, it provides GUI features on top of the
output of process or "action". I think the model/view approach lets us
unify the two things in the outputview. Currently I think the model is
enough, maybe a delegate will be needed later on to provide custom
drawing, but I don't see that atm.

> Most of the plugins may don't want to create and manage the custom model
> just to print out simple strings or clickable items.

Thats easily done: use qstandarditemmodel and connect to the signals
that the outputview will emit (I'm thinking about replicating the
QItemSelectionModel interface to a certain extent on the outputview
interface)

> That's the reason of existance of OutputView. If things get
> complicated, plugins will do their own.

Why? It gets confusing if you have half a dozen different dockwidgets
that provide some output-like information.

Andreas

-- 
You have an unusual understanding of the problems of human relationships.