GraphicsView / ModelView Integration ???

[travlr]

Hi all,

Abstract:

• I'm working on implementing/emulating this modular data exploration platform concept/functionality in Qt4.
• I tend to want to use the excellent Model/View framework as the core of all my data-centric applications.
• The Graphics View Framework is exciting and I'm still learning it.
• I see aspects of both Model/View and Graphics/View being needed for this to work for me.
  • Model/View as the interface to flexible and diverse back-end for my data items.
  • Graphics/View for the node/edge visual representation.
• I searched through relevant threads here on the forum without finding many clues to answer my questions.

Questions:

• First, I have always wondered why the Graphics View Framework isn't integrated with the Model View Framework? This would seem very logical to me.
• Since I need "edge" connectors between the graphical representation of my nodes, it seems this would require the Graphics View Framework... Is this correct?
• Can edges be drawn in Model/View alone?
• Can I use the Graphics/View as the front-end, and Model/View as the back-end interface in my application?
• Do you have any other comments or recommendations for me?

Thank you for your comments,
-travlr

[wysota]

First, I have always wondered why the Graphics View Framework isn't integrated with the Model View Framework? This would seem very logical to me.

I was asking myself the same question but at some point in time I stopped doing it - the architectures are just too different. Of course if you want to provide a model based access to the graphics view framework, it is possible and I even had plans to do it but never managed to start working on it.

Since I need "edge" connectors between the graphical representation of my nodes, it seems this would require the Graphics View Framework... Is this correct?

No, it's not required but it would simplify things a bit.

Can edges be drawn in Model/View alone?

Yes, you can draw anything you like if you use a custom view.

Can I use the Graphics/View as the front-end, and Model/View as the back-end interface in my application?

In theory - yes. In practice - hard to say at that stage, probably yes.

Do you have any other comments or recommendations for me?

Start with simple things (omit the model-view framework) and once you have it going with the graphics view, add more complexity (including the mvc component).

Good luck

[travlr]

Hi Wysota,

Thank you very much for your reply.

Start with simple things (omit the model-view framework) and once you have it going with the graphics view, add more complexity (including the mvc component).

I do have a working, preliminary graphicsview model. At this point I'm ready to implement the data item back-end. What I would like to do is utilize the QAbstractItemModel, but I guess you are recommending I implement my own MVC framework for the hierarchical back-end interface.

Is that correct? Would you add a little more specificity for me? I'm still learning.

Thank you kindly,
-travlr

[wysota]

. What I would like to do is utilize the QAbstractItemModel, but I guess you are recommending I implement my own MVC framework.

Is that correct?

No, it's not. You have to subclass QAbstractItemModel and wrap it around QGraphicsScene.

[travlr]

Yes, ok. I sort of see it now. So are you saying QAbstractItemView is not needed, because the QGraphicsScene is, in essence, the "model" to the QGraphicsView? I'll start working on this. Thank you very much.

[wysota]

So are you saying QAbstractItemView is not needed, because the QGraphicsScene is, in essence, the "model" to the QGraphicsView?

QGraphicsScene is a model for QGraphicsView. Just think if you need the model-view for something else, because if not, there is no point in implementing a model for the scene. In my case I wanted to show the object hierarchy using QTreeView and QGraphicsView at the same time, so I had no other choice but to implement a QAbstractItemModel subclass.

[travlr]

QGraphicsScene is a model for QGraphicsView. Just think if you need the model-view for something else, because if not, there is no point in implementing a model for the scene. In my case I wanted to show the object hierarchy using QTreeView and QGraphicsView at the same time, so I had no other choice but to implement a QAbstractItemModel subclass.

Yes, that's my intention too. I want to have a singular QAbstractItemModel interface to a multiplicity of views, including QAbstractItemView based views and the QGraphicsView. Which is why it kinda bothers me that its not naturally integrated already.

[wysota]

Which is why it kinda bothers me that its not naturally integrated already.

I think it would limit the GraphicsView framework too much.

[travlr]

I think it would limit the GraphicsView framework too much.

Well I'm definitely not familiar enough yet, but agree that there are most probably un-welcome limitations.

Just as you (have) and I (am trying to) implement an interface... I don't see the reason yet, why one isn't provided for such a natural, symbiotic relationship.

Come to think of it, though maybe not practical as is, I believe a Model/View architecture should be at the Qt core itself. ...Everything in life thats not, in some way, a portrayal of chaos... is in a natural hierarchical topology/taxonomy. This holds especially true in computer science, me thinks.

[wysota]

Come to think of it, though maybe not practical as is, I believe a Model/View architecture should be at the Qt core itself.

Funny... Andreas Hanssen (vel Bitto) thinks the same way about QGraphicsView

[Brandybuck]

Graphics view and Model/View are conceptually similar, but implemented very differently. However, there is no reason you cannot write a QAbstractIemView that uses QGraphicsScene/View for visualization. It would be a considerable effort, but the results could be very nice.

Alternatively, since QAbstractItemModel is merely a wrapper around the underlying data, you can always have the QGraphicsScene access that data directly, bypassing model/view.

[stefkeB]

Any hints or tips on the current approach in your implementation?

I was thinking the same thing for a computer-aided design application: a MVC framework for the data, but at the same time, multiple representations (treeview, diagram using GraphicsView, regular 3D view using OpenGL etc...).

Choose one? Combine both?