Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

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.


  • Moderators

    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



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



  • @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 :-)



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