Witold on OpenGL - for the third time
Witold just announced the third part of his OpenGL + Model-View article series. It is an interesting concept and shows that the model view solution can be applied to many parts of Qt. For example the QGraphicsView would also benefit from having a model holding the items. The different types of items would then be managed by different delegates...
posted by Johan Thelin @ 14:53
10 comments
10 Comments:
Yes, I thought about it as well and I'm in need of such a model for a rewrite of my Bachelour project, so sooner or later I'll be implementing a model holding QGraphicsItems. Maybe I can release it to public when it's ready.
What is more, when I first heard of QGraphicsView the name suggested that it'll be based around the Interview concept as well, but unfortunately it was not. In theory one could make a Interview view out of QGraphicsView, but is it worth it? It would just be a wrapper of one API over another.
Could you give more details about what you said about having different delegates for handling a QGraphicsScene related model? Maybe some examples? :)
QGraphicsView has a model, it's called QGraphicsScene. The view is called QGraphicsView and you can show your model (QGraphicsScene) in different QGraphicsView's, including one that can use OpenGL (by calling setViewport on the QGraphicsView, or inhering it correctly).
This comment will be in two parts:
#1 As you can treat the QGraphicsScene as a model, all that it takes is a QAbstractModel that wraps the graphics scene to make it available as a model.
#2 Delegates - the different shapes of a scene needs different amounts of data. By letting each row contain a separate shape (or should they be placed in a tree so that each node contains a shape) and then applying a delegate to that row/node, the delegate could be made responsible for creating an item that can be shown by the graphics view.
the delegate could be made responsible for creating an item that can be shown by the graphics view.
Don't you think the model should be responsible for this and not the view (meaning Interview view, not QGraphicsView)? The delegate is part of the view, so this would only apply when interacting through the view using a kind of hack as you'd have to first insert a dummy empty item into the model (and probably the scene as well), before you can edit it.
But generally the idea is fine and I was thinking about something simmilar.
You are probably right... I'm just writing as I think of a solution. I will probably have another solution after having written down the specs and getting some code in place... sometime, somewhere :-)
I was thinking about this and I doubt QGraphicsScene doesn't provide all the things needed to make a full featured model out of it... Example? It doesn't notify about the changes made to items. Although it has changed() and sceneTectChanged() signals, but I think they don't carry enough information to make a good model out of it. The rest of the model is possible to do though... (after all SQL models don't update themselves from the datasource as well...)
Thanks for pointing to these articles. And thanks a lot to wysota for writing them.
I've just slowly started to work on a KDE4 client for a 4x game based on Thousand Parsec framework. Here the objects of universe (space ships, planets, star systems, ...) and their properties are obtained from a server. So I was thinking about storing the objects localy in a model/view way that is provided by Qt4. This model would then be used to represent a starmap of objects (I am thinking about using QGraphicsView), a tree of objects and maybe in some other views.
So I'm currently reading a lot about Model/View programming with Qt4 and I think these articles will be very helpfull for learning about it.
So thanks again.
The designs are incompatible. In Qt/Interview (qabstractitemview), the view asks the delegate for the size of a cell, and the delegate returns a size based on the text and icon from the view's model. The delegate does not decide its own geometry, just the size of a cell. The _view_ owns the geometry. In Graphics View, the item owns the geometry. You don't get anything from wrapping a scene in a qabstractitemmodel when the view needs to ask the model for all geometry...
I just noticed the comment. This is true that the designs are different, but Qt has proven more than once that this is not a big problem to connect different technologies together.
My preposter said that the view asks the delegate to render an item at a position specified by the view. This is correct, but only for the views that are bundled with Qt itself. Nobody forces you to use delegates. In fact, if you take a look at the pie chart example that comes with Qt you'll see that it doesn't use the delegate at all and that it is the view accompanied by the model that decides where to position a particular item - so in fact the view asks the model for geometry.
The benefit of wrapping a graphicsview scene into a model is obvious - you can have different views on the same set of data. The model is the data logic, it doesn't have to be visualised in ANY view, it's just a means to store data. As for the GL model itself, imagine a generic view that renders the scene using OpenGL. I believe you can even incorporate the concept of delegates to alter the rendering.
I agree... I think we are headed to a unified object/display paradigm where any qobject/widget can be rendered to the screen. I find the graphicsview to be very easy to work with, but not functional enough. Where as the regular widgets are extremely functional, but not easy to layout if you want something that is not conforming to the envisioned layouts. I think primarily, of flash (macromedia). With the upcoming ecma script additions, it should be able to implement a completely open source, standards-based flash. But I digress... I desperately want to have the graphics view capability available for all widgets.
Post a Comment
<< Home