It would be nice to say what self and event are. I'm guessing a QGraphicsItem and a parameter of QGraphicsSceneMouseEvent? Is that right?
If so then event.pos() and event.scenePos() are not exchangeable. The first one is cursor position in item's coordinates and the second one cursor position in scene coordinates. They are the same only when item is placed at (0,0). If item is moved they will differ. It's important to note that these values are what they were at the time the event took place, which might be different from the "current" values for item (this is a good thing). For example if you move your mouse fast and there are a lot of events generated the cursor position in these events will be a little behind the actual current position of the cursor before they "catch up".
As for self.scenePos() - this is the position of the item in the scene. This is the point relative to which the event.pos() is calculated. It is not necessary the top left of the bounding rect. It can be placed anywhere using 'setTransformOriginPoint()'. It is often set to the center of the item. For example if you have a bunch of draggable circles a center is probably more convenient than a top left corner. For vertical bars on a chart the origin might be placed at the middle bottom of a bar etc.
No, I didn't set these two flags ItemClipsToShape, ItemClipsChildrenToShape.
Then I tried setting only one flag ItemClipsToShape, and both of ItemClipsToShape, ItemClipsChildrenToShape. For each, it still check if the point is in the boundingrect() firstly, and then check the shape() which means if point is not in boundingrect(), it wouldn't bother to check shape().
So now my solution is still enlarging the boundingrect() area.
To elaborate on your answer: The boundingRect() must include every pixel that you intend to paint to in your own item's paint method. That includes e.g. pixels that are outside your item proper, but painted to due to a wide pen.
(Calculating the correct boundingRect for items with wide cosmetic pens can be a real pain.)
Well, I re-implemented the whole mouse moving the puzzle shape thing. I am not using itemChanged() override anymore. The fact that the item's position x and y was not the same as the boundingRect().topLeft() x and y after rotating was an issue that was too problematic. A tangram shape; a right triangle with a hypotenuse that equaled the leg * the square root of 2 being contained by a bounding rectangle during rotation produced too many effects. So, I got it working, and very well, but I ended up using
void PuzzlePiece::mouseMoveEvent(QGraphicsSceneMouseEvent *event)
QRectF rect = scene()->sceneRect();
float mx = event->scenePos().x() - xbeta;
float my = event->scenePos().y() - ybeta;
\\ sets the boundingRect to the bounds of the actual polygon points
And yes, the shape stops moving when it goes out of the scene, but a mouseDown sets it position back inside the scene and all is good.
I made a tangram puzzle application way back when I was a young man. I used Cocoa/Objective C on a Mac. The thing was downloaded over 8 million times in a week. People from Japan would call me up and ask me about it. It was crazy. And yeah, it was free, so I am not a millionaire; my wife yelled at me for weeks for making it free. It was this small window about the size of an smart phone screen.
Cocoa does not have a simple implementation to make an graphic item movable with some easy setFlag(QGraphicsItem::ItemIsMovable). It was much more difficult to implement back then. So, I am basically using the same bounds checking and resetting the object the same way as I did 25 years ago.
My son is about to go to college for software engineering. I am teaching C++ with the implementation of this simple puzzle.
Thanks for your help. Your posts kept me thinking!
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.