I'm currently implementing a custom delegate, in part of which I need a QSpinBox to be drawn in the paint(..) method.
void Sy_floatingPointPD::paint( QPainter* painter,
const QStyleOptionViewItem& option,
const QModelIndex& index ) const
{
painter->save();
// Paint check box.
QStyleOptionSpinBox spOpt;
spOpt.palette = option.palette;
spOpt.rect = option.rect;
spOpt.state = option.state;
spOpt.frame = true;
spOpt.stepEnabled = QAbstractSpinBox::StepUpEnabled |
QAbstractSpinBox::StepDownEnabled;
style->drawComplexControl( QStyle::CC_SpinBox, &spOpt, painter );
painter->restore();
}
Unfortunately it appears as:
As you can see the step buttons are drawn massive and only the down arrow appears. Interestingly the width of the buttons mirrors that of the first table column, despite option.rect being the size of the cell (which is correct, which is presumably why the frame is drawn correctly).
Any ideas what information I'm not giving QStyle?
Jens over at the qt-project forums answered this question, so I'll link to it here.
In short, there is a design flaw in the spin box drawing (at least in QGtkStyle) whereby it only uses the size of the option.rect, ignoring it's position. Although this perfectly reasonable in a 'normal' painting scenario because it maps to the widget origin, it fails when rendered in an item view due to the cell offset.
To solve this, move option.rect to the widget origin (i.e. move it's top left corner to (0,0)), and then translate the QPainter to take into account the cell offset.
Related
After hours of work, I'm able to paint a widget on QListView. However, the painting is done through a QPixmap. The widget appears, and I can see a progress bar. However, it's a little "pixelated" (due to using QPixmap). Is it possible to paint directly as a normal widget? That's my question.
The following is what I do:
void FileQueueItemDelegate::paint(QPainter *painter, const QStyleOptionViewItem &option, const QModelIndex &index) const
{
QPaintDevice* original_pdev_ptr = painter->device();
FileQueueListItem* itemWidget = reinterpret_cast<FileQueueListItem*>(index.data(Qt::UserRole).value<void*>());
itemWidget->setGeometry(option.rect);
painter->end();
QPixmap pixmap(itemWidget->size());
if (option.state & QStyle::State_Selected)
pixmap.fill(option.palette.highlight().color());
else
pixmap.fill(option.palette.background().color());
itemWidget->render(&pixmap,QPoint(),QRegion(),QWidget::RenderFlag::DrawChildren);
painter->begin(original_pdev_ptr);
painter->drawPixmap(option.rect, pixmap);
}
I learned how to do what I did with the hints from here. There, the painting is done directly on QListView, which is what I'm looking to achieve. What am I doing wrong for the following attempt not to work:
void FileQueueItemDelegate::paint(QPainter *painter, const QStyleOptionViewItem &option, const QModelIndex &index) const
{
std::cout<<"Painting..."<<std::endl;
QPaintDevice* original_pdev_ptr = painter->device();
FileQueueListItem* itemWidget = reinterpret_cast<FileQueueListItem*>(index.data(Qt::UserRole).value<void*>());
itemWidget->setGeometry(option.rect);
painter->end();
if (option.state & QStyle::State_Selected)
painter->fillRect(option.rect, option.palette.highlight());
else
painter->fillRect(option.rect, option.palette.background());
itemWidget->render(painter->device(),
QPoint(option.rect.x(), option.rect.y()),
QRegion(0, 0, option.rect.width(), option.rect.height()),
QWidget::RenderFlag::DrawChildren);
painter->begin(original_pdev_ptr);
}
The list just remains empty, and nothing happens. Though the selection can be seen, but the widget doesn't show up.
Let's make a few things clear:
You're not supposed to create widgets and put them in a model. There's a very good reason for this. Widgets are involved in the Qt event loop, which means that having too many widgets will significantly slow down your program.
Widgets are not simply a bunch of controls (which seems to be how you see them). They take part in the event loop, which is why you should not have a widget that's a part of a data model.
If you're using a multithreaded program and you have our model separated from the view, memory management will become a nightmare. Qt will never tolerate trying to construct or delete any widgets from other threads (which makes sense, since detaching threads from the event loop is not generally thread-safe).
Given this information, what's the right way to do what you're trying to do? Sadly the only correct way is to draw the controls yourself. If your widget is simple, that's easy to do. If your widget is complicated, you're gonna need lots of math to calculate the positions of every widget.
In the Qt Torrent Example, you'll see how a progress bar is drawn. All you have to do to draw your controls, is calculate the position, and use the rect member variable as the containing rectangle of the controls, and then draw them (of course, after setting their values). The function paint() has an option.rect parameter in it, which is the rectangle of the whole item. All you have to do, is use some math to calculate the positions inside this rect for every widget.
PS: NEVER USE ABSOLUTE VALUES FOR THE POSITIONS. You will never get it right, especially for different DPIs.
That will draw the controls without widgets, and will guarantee the speed you need even for thousands of elements.
I do have 2 QDeclarativeItems.
void BackgroundLayer::paint(QPainter* painter, const QStyleOptionGraphicsItem* option, QWidget* widget)
{
painter->drawImage( QRectF(dx1, dy1, dx2-dx1, dy2-dy1), shownImage, QRectF(sx1, sy1, sx2-sx1, sy2-sy1) );
}
void ForegroundLayer::paint(QPainter* painter, const QStyleOptionGraphicsItem* option, QWidget* widget)
{
QPen pen(Qt::red, 3, Qt::SolidLine, Qt::RoundCap, Qt::RoundJoin);
painter->setPen(pen);
painter->drawLine(p1, p2);
}
QML
Rectangle {
width: 1920
height: 1080
BackgroundLayer{
id: background_layer
anchors.fill: parent
}
ForegroundLayer {
id: foreground_layer
anchors.fill: parent
}
}
Drawing on ForegroundLayer triggers BackgroundLayer paint event, causing it to repaint the whole image. As a result, drawing works slow. Is it possible to avoid this and repaint the image only when it's really needed?
Why do you expect any other kind of behavior? Qt doesn't keep the images of every declarative item for you, it'd be prohibitively expensive in terms of memory. You have the option of enabling this, though: perhaps you should. See the cacheMode documentation.
When any item needs to be updated, everything underneath and intersecting the update rectangle has to be repainted too, in the Z order from bottom to top. If there are any widgets underneath the QGraphicsView and if the view itself is translucent, then these widgets will have to be repainted as well.
If you have knowledge exactly of what area needs to be updated, you should use that knowledge: call QGraphicsItem::update(const QRectF &) to indicate the bounds of what needs updating. Otherwise, with a null rectangle, the update region spans the whole item.
Also ensure that the QGraphicsView's updateMode is set to MinimalViewportUpdate.
Under the covers, all QGraphicsItem instances and all QWidget instances all paint on an internal QImage that is then blitted or swapped into the underlying native window. They paint in back-to-front Z order, and the only widgets or items that are skipped are those that are completely contained under an opaque widget or item.
Short answer : Just use a QPixmap converted once from shownImage
void BackgroundLayer::paint(QPainter* painter, const QStyleOptionGraphicsItem* option, QWidget* widget)
{
painter->drawPixmap( QRectF(dx1, dy1, dx2-dx1, dy2-dy1), shownPixmap, QRectF(sx1, sy1, sx2-sx1, sy2-sy1) );
}
Explanation :
painting pixmaps on screen is much faster than images. The other choices may not work or are way too complex.
Paint events propagate from the top widgets to their children, recursively.
Basically Qt is given a rectangle to paint, and every widget inside this rectangle will receive a paint event.
I am sure what you want to achieve might be doable in some specific cases with widget attribute hacking, but I fail to see how you can do it here without having old paint artifacts from the ForegroundLayer.
Let say you have two lines AB et CD.
After the first call to paint you only want to see line AB
After the p1, p2 have been updated you only want to see line CD
In order to prevent you from seeing the line AB when painting CD, Qt has to clear the entire background in the rectangle being painted. If for some reason BackgroundLayer doesn't paint, the background image will disappear.
I need my QGraphicsView to react on user selection - that is, change display when user selects area inside it. How can i do that?
As far as i can tell, selection in Qt Graphics framework normaly works through selection of items. I haven't found any methods/properties that touch on selected area, save for QGraphicsVliew::rubberBandSelectionMode, which does not help.
After some going through documentation, i found different solution.
In QGraphicsView there is a rubberbandChanged signal, that contained just the information i wanted to use. So, i handled it in a slot, resulting in the handler of following form:
void
MyImplementation::rubberBandChangedHandler(QRect rubberBandRect, QPointF fromScenePoint, QPointF toScenePoint)
{
// in default mode, ignore this
if(m_mode != MODE_RUBBERBANDZOOM)
return;
if(rubberBandRect.isNull())
{
// selection has ended
// zoom onto it!
auto sceneRect = mapToScene(m_prevRubberband).boundingRect();
float w = (float)width() / (float)sceneRect.width();
float h = (float)height() / (float)sceneRect.height();
setImageScale(qMin(w, h) * 100);
// ensure it is visible
ensureVisible(sceneRect, 0, 0);
positionText();
}
m_prevRubberband = rubberBandRect;
}
To clarify: my implementation zooms on selected area. To that effect class contains QRect called m_prevRubberband. When user stop selection with rubberband, parameter rubberBandRect is null, and saved value of rectangle can be used.
On related note, to process mouse events without interfering with rubber band handling, m_prevRubberband can be used as a flag (by checking it on being null). However, if mouseReleaseEvent is handled, check must be performed before calling default event handler, because it will set m_prevRubberband to null rectangle.
You can use qgraphicsscenemouseevent.
On MousePress save the current position and on MouseRelease you can compute a bounding rect using the current position and the MousePress position.
This gives you the selected area.
If you need custom shapes you could track the mouse movement (MouseMove) to get the shape.
An Example that uses qgraphicsscenemouseevent can be found here.
QT 4.7
I have a QGraphicsView / QGraphicsScene. The scene has a custom QGraphicsItem the whole scene is not displayed at one time, so it has a viewport.
I'm overriding the paint() method of my QGraphicsItem as follows:
void paint(QPainter *painter,
const QStyleOptionGraphicsItem *option,
QWidget *widget)
{
painter->setClipRect(option->exposedRect);
painter->save();
// Default identity matrix
QTransform transform;
// Apply some transform later
// The next line breaks stuff
painter->setTransform(transform);
// m_image is just a preloaded pixmap (i.e. watermark on all of these items).
painter->drawImage(QPoint(0,0), this->m_image);
painter->restore();
// Snip, do more drawing...
}
If I ever try to setTransform on the QPainter (i.e. if I'm trying to rotate the item), the view stops repainting the scene as a response to the horizontal or vertical scrollbars used to pan. The view also stops resizing the scene when I zoom in or zoom out.
The view will refresh if I resize the window or drag the window offscreen and then back onscreen. I've been looking over the QPainter Documentation as well as the examples and I can't quite figure out what I'm doing wrong. I'm assuming it's something to do with the coordinate system.
A guess:
The QPainter that comes to your paint method already has a transform on it that takes into account the viewport attributes (scale, rotation, etc.). When you call setTransform within your paint method you are blowing all that away. You probably want to perform a matrix operation on the existing transform rather than creating a new one.
Since you are calling setClipRect on your painter but then trying to paint under a completely different transform, you are painting outside your clip rect and nothing is happening.
It works when you resize or drag the window off screen because that forces a "redraw everything," so your clip rect includes your painting area in your alternate transform. Although I'm surprised it would appear in the correct location.
I am trying to make a custom widget in Qt Creator that supports dragging objects around. At its simplest form, the widget has a QRect (or any other shape), on which I can click and then drag it around the widget. Once I release the mouse button, the QRect should stop being dragged.
In my QWidget class, I have this method
void ImageArea::mouseMoveEvent(QMouseEvent *event)
{
QPoint mousePos = event->pos();
qDebug() << mousePos.x();
qDebug() << mousePos.y();
qDebug() << "---------";
}
that can get the coordinates of the mouse as the pointer is moved around the screen. I have tried updating member variables for x and y, and then painting the QRect via the paintEvent method, but this doesn't work.
Does anyone have any suggestions?
To get mouse move events, you must set the QWidget::mouseTracking property to true:
ImageArea::ImageArea( QWidget* p ) : QWidget( parent ) {
...
setMouseTracking( true );
}
Implement paintEvent(QPaintEvent *) to draw the object(s) at the positions indicated by the current value(s) of their corresponding member variables.
After you've changed the values of one or more member variables (in mouseMoveEvent or wherever), call this->update(). That will tell Qt that it needs to call your paintEvent method again in the near future.
That should be all you need to do.
Be sure to use the moveTo method to move the rectangle.
Setting the x,y position directly may affect the size of the rectangle.
I don't see what you aren't doing, based on your question.
Are you sure that the rectangles are in new positions when you paint them?
Maybe you are missing the update step Jeremy Friesner told to implement.
It seems that you are missing mouse button tracking.
The easy way might be to get the mouse button states from QApplication::mouseButtons(). Although it might be slightly less efficient.