@mrjj . Thanks a ton for your help. Its working perfectly.

@Chris-Kawa Noted thank you. Now it compiles without errors. I think I need to read a bit about newer c++...

Ohhh i thought so about implementing my own flow layout. Tried to avoid this, because this will be difficult to do, but if there is no other way... Anyway, thank you. You helped me to understand a little graphics view framework and saved a lot of time. Best regards!

Are you thinking of the new RHI abstraction layer ?

@MegAmaNeo1 In @jsulm's outline code you need a signal named pressed in CustomItem for connect(&item, CustomItem::pressed ..., and you also need an array/QVector of bool named pressed for pressed[i]. You'll presumably need to rename one of them. And where he writes void QGraphicsItem::mousePressEvent he means your void CustomItem::mousePressEvent override.

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

@newToQt26 Hi Good to hear. :) If the user can add or delete layers, it's pretty important you make sure curScene/curView always points to something valid as else you get a nasty crash.

@incam https://doc.qt.io/qt-5/qpropertyanimation.html

@lansing https://doc.qt.io/qt-5/qwidget.html#enabled-prop https://doc.qt.io/qt-5/qgraphicsview.html#focusInEvent

@Dariusz Ok so you could get the 40K sample to lag also ?

Probably not the cleanest solution, but a workaround would be to use an eventFilter. The QGraphicsView could call widgetName->installEventFilter(this) Then in the QGraphicsView, you override the method "eventFilter". That should receive the event originally destined to your widget. Be careful, handling event coordinates can be a bit messy.

Hi Ok try with that on and see if it then get the mouse events.

@Another-Qt-Beginner Hi Did you try setting https://doc.qt.io/qt-5/qgraphicsview.html#ViewportUpdateMode-enum to FullViewportUpdate to see if that reduces the issues.

Hi, What exactly is not working ?

Also another problem with path.contains that I find is that the contains would use this as check area > https://doc.qt.io/archives/qt-4.8/images/graphicsview-pathitem.png Which means that the shape can be bigger/inaccurate comparing to the selection location... I think I will need to do some math and create another method for path click intersection. Ok I sorta managed to "fix" it... I ended up creating a forward and then reverse path during selection process. So that the path is a closed - precise - shape. This way I can get proper click detection, I still cant compute which path is closer, but at least selection works properly now.