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

@mrjj Yes, it worked. Thank you!

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

@lansing I'm not sure what you are trying to achieve. Normally, I would calculate the correct bounding rect (and ideally cache the result as long as nothing changes, so calls to boundingRect() stay fast)

It appears that QGraphicsScene checks if position of item is visible in view and then draws/dont draws it... returning qgraphicsScene->sceneRect() as boundingRect on my curve "solved" the issues but its a problem for selectable items... hmmm

@SGaist Its about precision moves, if user wants to move by tiny bit, scaling mouse movement by x value would allow that to happen. Else he would have to type 0.0001 0.0002 0.0003 etc etc. I think I could handle it using itemChange() and record initial mouse click press/release and calculate delta using that.. Yep that seem to do the trick... I can now move my items by tiny amount and doing "Long precise drags" deltaX = (newPos.x() - self.mMousePressPosition.x()) / 2 newPos.setX(newPos.x() - deltaX) deltaY = (newPos.y() - self.mMousePressPosition.y()) / 2 newPos.setY(newPos.y() - deltaY) Small edit, function above works for "simple" items, but as soon as I get to child items with parent it appear to break... sigh. Needs some more math there

Hi I think you just broke GraphicsView normal handling. Try also calling base class mousePressEvent as it might use for the actual item selection void GraphicsView::mousePressEvent(QMouseEvent *event) { if(event->buttons().testFlag(Qt::LeftButton)) { int x,y; x = event->pos().x(); y = event->pos().y(); qDebug() << x << ", " << y; QPointF point = mapToScene(x, y); QGraphicsEllipseItem *ellipse; ellipse = scene->addEllipse(point.x(),point.y(),5,5,QPen(Qt::red), QBrush(Qt::red)); ellipse->setFlag(QGraphicsEllipseItem::ItemIsMovable); } // call base class QGraphicsView::mousePressEvent(event); }

@sgaist Hmmmmmmmmm I wrote a little routine to use mouse press/release to see what has changed to determine my selection but it does not work as well as I wish. But I missed that focusItemChanged mhmhmhmh thanks! Will go over it again :- )

I've updated the question with gif/some updates... Still fighting with it o.o I think by using int vertOffset = horizontalScrollBar()->sliderPosition(); I can somehow calculate the "jump" value offset and offset position of line by that. Not sure how yet tho...

Hi, Without more details form you side, it looks like that's the function you are looking for.

Call fitInView on the GraphicsView with the Image whenever the size of the GraphicsView changes. The rest should work automatically.

@Skamath The Halcon example using Qt is very simple but it uses the Halcon Graphics Window to show images, regions and XLDs. If you think that it is complicated I recommend you to use the Halcon Graphics Window instead of trying to build your own Graphics Window based on QGraphicsView.

Thanks @SGaist and @raven-worx , I try both methods to see which one to use better in my program.

@Staslend if your issue is solved, please don't forget to mark your post as such! Thanks.

Hi, You should add: Which version of Qt you were using before Which version of Qt you are using now Graphics card + driver Platform you are running on

The idea is that you have your container widget getting resized and in its resize event, you change the size of the inner widgets with the ratio you want.

@Niagarer Good found. :)

Thanks for the input! I think I'm going to go with QGraphicsView for the notation and use QQuickWidgets throughout the other pieces of the UI that don't need access to the entire model. I'm hoping that won't be too complicated and will give me the best of both worlds. But I do wonder: is there a specific piece of Qt Quick that's supposed to a "replacement" for QGraphicsView? It seems like the scene graph is a bit too low level, but it's also the only way to gain a lot of control and keep things mostly on the C++ side. It would be nice if the built-in QML elements are exposed via a C++ API at some point.

@mrjj There are other obstacles that I need to overcome. But this way seems to be the solution that i am implementing. Thanks

Do you mean custom graphicsView or tableView? If custom graphics view wouldn't it be too hard to reimplement everything? Any links or example would help.

In your MyView::paintEvent write QPainter painter(viewport()); instead of QPainter painter(this);.