Future of QGraphicsView and QGraphicsScene
-
Some years ago, there was a QT blog post essentially stating that one should avoid QGraphicsView for new implementations.
How up-to-date is this warning today? What are the middle- to long-term plans for QGraphicsView?I'm maintaining a widget-based software module visualizing industrial data in custom diagrams. It's very customizable, interactive, may display thousands of objects at once and is highly performance-critical. It originiates from QT3 times, and uses a custom paint framework around QPainter. I'd love to migrate to QGrahicsview/-scene which covers most of our needs out of the box, but am hestitant to switch to something which will be deprecated in a while. However, I don't see that QML is up to the task for a long while.
-
QtGraphiscView is not deprecated and is not going away. It's also mature and feature-rich. You can safely port to it, in my opinion.
If you want concrete plans from Qt project though (if there are any), ask on Qt Development Mailing List.
-
To my knowledge (and I dug hard and long), there is no adequate replacement for GraphicsView either existing or planned. It covers use-cases neither covered by QML nor Widgets nor Qt3D
-
Some years ago, there was a QT blog post essentially stating that one should avoid QGraphicsView for new implementations.
How up-to-date is this warning today? What are the middle- to long-term plans for QGraphicsView?I'm maintaining a widget-based software module visualizing industrial data in custom diagrams. It's very customizable, interactive, may display thousands of objects at once and is highly performance-critical. It originiates from QT3 times, and uses a custom paint framework around QPainter. I'd love to migrate to QGrahicsview/-scene which covers most of our needs out of the box, but am hestitant to switch to something which will be deprecated in a while. However, I don't see that QML is up to the task for a long while.
@bewi said in Future of QGraphicsView and QGraphicsScene:
However, I don't see that QML is up to the task for a long while.
QML (Quick), graphics view, and widgets don't need to be mutually exclusive. QQuickWidget plugs into an application in similar fashion to QGraphicsView.
-
@bewi said in Future of QGraphicsView and QGraphicsScene:
However, I don't see that QML is up to the task for a long while.
QML (Quick), graphics view, and widgets don't need to be mutually exclusive. QQuickWidget plugs into an application in similar fashion to QGraphicsView.
@jeremy_k said in Future of QGraphicsView and QGraphicsScene:
@bewi said in Future of QGraphicsView and QGraphicsScene:
However, I don't see that QML is up to the task for a long while.
QML (Quick), graphics view, and widgets don't need to be mutually exclusive. QQuickWidget plugs into an application in similar fashion to QGraphicsView.
Try to write a powerpoint-like editor in QML. GraphicsView is perfectly suited for this job.
-
@jeremy_k said in Future of QGraphicsView and QGraphicsScene:
@bewi said in Future of QGraphicsView and QGraphicsScene:
However, I don't see that QML is up to the task for a long while.
QML (Quick), graphics view, and widgets don't need to be mutually exclusive. QQuickWidget plugs into an application in similar fashion to QGraphicsView.
Try to write a powerpoint-like editor in QML. GraphicsView is perfectly suited for this job.
@Asperamanca I think my point was missed. There's no need to choose Quick|Graphics View|Widgets for the entire application. Use each where they make sense and use the underlying Qt core functionality to communicate.
-
@Asperamanca I think my point was missed. There's no need to choose Quick|Graphics View|Widgets for the entire application. Use each where they make sense and use the underlying Qt core functionality to communicate.
@jeremy_k said in Future of QGraphicsView and QGraphicsScene:
@Asperamanca I think my point was missed. There's no need to choose Quick|Graphics View|Widgets for the entire application. Use each where they make sense and use the underlying Qt core functionality to communicate.
Yes, I missed your point. But maybe you missed mine: There is currently no better technology (in Qt) for some use cases than GraphicsView. Of course I can mix and match, depending on what I need. I took that as given :-)
-
@jeremy_k said in Future of QGraphicsView and QGraphicsScene:
@Asperamanca I think my point was missed. There's no need to choose Quick|Graphics View|Widgets for the entire application. Use each where they make sense and use the underlying Qt core functionality to communicate.
Yes, I missed your point. But maybe you missed mine: There is currently no better technology (in Qt) for some use cases than GraphicsView. Of course I can mix and match, depending on what I need. I took that as given :-)
@Asperamanca said in Future of QGraphicsView and QGraphicsScene:
@jeremy_k said in Future of QGraphicsView and QGraphicsScene:
@Asperamanca I think my point was missed. There's no need to choose Quick|Graphics View|Widgets for the entire application. Use each where they make sense and use the underlying Qt core functionality to communicate.
Yes, I missed your point. But maybe you missed mine: There is currently no better technology (in Qt) for some use cases than GraphicsView. Of course I can mix and match, depending on what I need.
No, I didn't.
We're in agreement there. It's easy to look at the graphics silos and forget that they can cooperate.
