How can I use QPainter to paint on QGraphicsView?
-
Hi
Normally you would make a custom widget based on QWidget and
use http://doc.qt.io/qt-5/qgraphicsproxywidget.html
to have it in scene.
Drawing directly on the view would make it impossible to have support for
all the features of moving / zooming etc. -
Hi and welcome to devnet,
Are you looking for something like the Scribble example ?
-
hi @elmLiu and Welcome!
First of all, if you are going to use a QGraphicsView, always use the QGraphicsScene! I draw and interact with 10000s of elements (lines, arcs, text, points, etc.) and have real-time panning, zooming, and rotation at least 20Hz (I have clocked it at 100Hz) for the moving map! Actual mouse interaction is instantaneous.
If all you want to do is draw something yourself, derive your own QGraphicsScene override the drawForeground method. This will give you the ability draw anything you desire.
I use drawForeground to draw things like a site scale, compass rose, vehicle, or a navigation overlay over the linework and surfaces. If you do not want to have widgets as part of your scene, the QGraphicsView accepts and works nicely with layouts (see buttons on the right of the plan screen).
Don't be afraid!
-
@Buckwheat Hi, before trying to use QGraphicsView & QGraphicsScene, I customized QWidget Class as my canvas, setting it central widget, and used mousePressEvent & mouseMoveEvent & mouseReleaseEvent & paintEvent to instantly update my canvas while using mouse to draw geometries, and also, to detect certain points on geometries such as end point & mid point. So far I've made it happen, but I just don't know how to do the same using QGraphicsView & QGraphicsScene.
Which part can the drawForeground method do? I know that all items are stored in Scene and displayed via View, but in which class or whose method shall I try to instantly update my canvas?
I'm new to Qt, may you forgive my doubts :) -
Hi @elmLiu
I was new to Qt back in 2012. You will find that you will learn to use it quickly. Being older (and hopefully wizened) I find that a lot of people like to build Qt from scratch (why I do not know). I just want to use it and learn it. It makes developing fun in some respects.
Please derive MyGraphicsScene from QGraphicsScene and override mousePressEvent, mouseMoveEvent, mouseReleaseEvent and if desired, wheelEvent. These will give you the mouse position and the last mouse position in scene coordinates in QGraphicsSceneMouseEvent. From there you can do your magic! I pan, rotate, zoom, select, etc. using
Again, if you wish to manage your own data and paint it yourself, you can override drawBackground (always is the bottom layer) and drawForeground (always the top layer) and you will have complete control. I do a mixture of both. As I do not want to manage 10000s of items but only the overlays I need.
Unfortunately, if you want complete control of zooming, you have to jump through hoops to disable the scrolling features. I had to do this because of the nature of my work. I consider this the only problem with QGraphicsView. I will there were two classes: QGraphicsView (no scrolling at all and acts more like a pure painter) and QGraphicsScrollView (this woudl behave like the current).
Enjoy!
-
In your
MyView::paintEventwriteQPainter painter(viewport());instead ofQPainter painter(this);. -
For those who still want to draw on a QGraphicsView instead of a viewport. For example when you set margins around the viewport with serViewportMargins() and want to draw something in that free space around the viewport.
The quick answer:
QPainter painter(this); in paintEvent() - leads to an error 'QWidget::paintEngine: Should no longer be called'.Instead of overriding painteEvent() you need to go with the overriding event() for events with QEvent::Paint type.
bool MyGraphicsView::event(QEvent* e) { const bool result = QGraphicsView::event(e); if (e->type() == QEvent::Paint) { QPainter painter(this); // No errors // paint what you need } return result; }The longer answer:
Usually, all events for widgets come to event() function. The type of the event is checked and for example events with QEvent::Paint type are redirected to painterEvent() function, or events with QEvent::Resize type are redirected to resizeEvent() function, and so on.But that works in a different way for QAbstractScrollArea which is the base class for QGraphicsView. If you look into sources of QAbstractScrollArea::event() then you can see that there is some drawing code (btw calling QPainter p(this) with no errors) and the code follows to QFrame::paintEvent() instead of paintEvent(). But when paintEvent() of QGraphicsView is called then? It's called when the viewport widget (child widget) receives QEvent::Paint event.
As you can know QWidget is the sub-class of QPaintDevice. But painting in fact can occur not on the widget itself but on so-called "redirected" painting device (probably the top-most parent, see QWidgetPrivate::setRedirected). The usual flow is next:
- set redirected device for the widget
- send paint event for the widget
- handle event in event() and redirect it to paintEvent()
- restore redirected device for the widget (set it to nullptr)
So when the paint event is handled in QAbstractScrollArea::event() the redirected device for QGraphicsView is valid and there are no errors when creating and using a painter object.
But when QAbstractScrollArea::paintEvent() is called the redirected device of the QGraphicsView is already restored and now it's enabled for the viewport widget instead. So at this moment using
QPainter painter(this) causes an errors
QPainter painter(viewport()) doesn't cause any errors.I don't think that qt developers made that intentionally so no one can draw on the QGraphicsView. I hope that will help someone:)
