What is the point of having a graphicsview inside a graphicsview?
What is the point of having a graphicsview inside a graphicsview?
Why not ? After all QGraphicsView is a widget like the others.
I'm using QGraphicsView as a list item container for both Widgets and QGraphicsItems.
Last edited by bunjee; 9th October 2008 at 10:13.
I'm on Qt 4.4.3 Windows.
Consider the following code :
Qt Code:
group->setScene(scene); group2->setScene(scene2); group->scene()->addWidget(group2); group2->scene()->addWidget(lineEdit); // <<< The trouble maker group->show();To copy to clipboard, switch view to plain text mode
There is no way to add a widget inside a QGraphicsView that is embedded into another one.
I'm looking for an explanation for :
Why doesn't this work:
Qt Code:
group->setScene(scene); group2->setScene(scene2); group->scene()->addWidget(group2); group2->scene()->addWidget(lineEdit); // <<< The trouble maker group->show();To copy to clipboard, switch view to plain text mode
If there is any.
Yes, I can imagine embedding a GV into a GV was not forseen by the team who implemented "widgets on graphics view". I really don't see why anyone would want to embed a widget into a graphicsview that is embedded into a graphicsview. You can have the same functionality with much simpler design...
In that case that statement in Qt doc is not really true :
They are simpler design, but they are a huge flexibility trade-off.The QGraphicsProxyWidget class provides a proxy layer for embedding a QWidget in a QGraphicsScene.
QGraphicsProxyWidget embeds any QWidget-based widget
What I'm trying to do is the following :
I'm coding a custom graphicsView based list that supports the following :
- Mixing QGraphicsItem and QWidget seamlessly.
That way I'm getting the best of both world : having a QWidget enabled list that also supports QGraphicsItem in case I need 10 000 low memory items.
(As you can see I don't like the concept of model view delegates).
I've also developped my own QGroupBox based on my QGraphicsView list which also supports both QGraphicsItem and widget.
Only problem is when I mix my list and my groupBox with a QWidget, QPainter error blows up.
I think that might be a Qt 4.4.3 design flaw.
Last edited by bunjee; 10th October 2008 at 01:18.
So open the appropriate source file of the reference and change "any" to "almost any" and then focus on finding solution to your problem.
Somehow I don't see a tradeoff of substituting a graphicsview with a graphicsitem.They are simpler design, but they are a huge flexibility trade-off.
You could probably call it a bug, but on the other hand I completely understand this "improper" behaviour. Again I suggest to substitute the internal view by an item containing other items. Keep in mind that "widgets on graphics view" is a relatively new and very complicated architecture that required many internal changes to Qt in various places. Don't expect it to do everything without problems. Your problem is probably because two different views at once try to paint the same widget which is an abnormal situation.Only problem is when I mix my list and my groupBox with a QWidget, QPainter error blows up.
I think that might be a Qt 4.4.3 design flaw.
Well the solution is to get hired by the trolls to modify QGraphicsView design... or report a bug :-). I don't see any valid solution that is not a hack.So open the appropriate source file of the reference and change "any" to "almost any" and then focus on finding solution to your problem.
Consider the following scenario : you're coding a KDE like desktop widget that supports various transformations and animations.Somehow I don't see a tradeoff of substituting a graphicsview with a graphicsitem.
- You inherit QGraphicsView.
- Now you're adding your widget window items using scene()->addItem().
- One of them happens to contain a QGraphicsView representing some random diagram... You're screwed.
When you're looking at other modern GUI like say cocoa / core animation. They are some animations / interactions and opengl components that you simply cannot do properly using current Qt release. Because your whole widget is never based on some vectorial QGraphicsView representation. So most of your Qt app design is last century.
Which will - hopefully - change in 4.5.
Yeah but if you do that you're reinventing the wheel for each specific "group" item, why can't we be generic ?Again I suggest to substitute the internal view by an item containing other items
And you cannot use a QGraphicsItem coupled with a QWidget in something else than QGraphicsView.
So be sure not to do that. Qt is not perfect and it can't do everything. As for now we have to live with it.
Well... I don't think they allow you to do some things graphics view enables you to do...When you're looking at other modern GUI like say cocoa / core animation. They are some animations / interactions and opengl components that you simply cannot do properly using current Qt release.
I don't see any reinventing the wheel here. You want an item containing other items. For me it looks like QGraphicsItemGroup.Yeah but if you do that you're reinventing the wheel for each specific "group" item, why can't we be generic ?
Yes, and you can't do many other things as well, like drawing widgets from external threads. Just accept it and focus on solving your problemAnd you cannot use a QGraphicsItem coupled with a QWidget in something else than QGraphicsView.
Bookmarks