itemChange() problem

Oatmeal

@SGaist
SGaist, thank you for the interesting example, but it didn't get me any further in answering the question what I'm doing wrong in my itemChange() approach above. The colliding mice don't make use of itemChange().

JonB

@Oatmeal
Please bear in mind that I know nothing about QGraphicsScene, but....

Clearly from what you say you observe it's "too late" by the time the itemChange event handler is called --- I presume Qt has already moved the item, and returning a new position works but causes a flicker-move-redraw. Correct?

If so, it seems to me you'll need to handle the situation earlier, before the undesired move has happened. Can you instead intercept/handle the "drag" event, calculate the fact that it would move the rectangle to an undesired position, and deal with there? (Assumes that comes before the item is actually moved.)

Else you'll have to handle it at the MouseMoveEvent stage. And I think https://stackoverflow.com/a/13102984/489865 might give you enough idea to alter for what you need? Also perhaps look at https://stackoverflow.com/a/4161542/489865 ?

Asperamanca

I do something similar (although in C++), and it works for me. The only difference I see between our approaches is that, instead of directly returning the corrected value, I call the base class itemChange method with it.

Oatmeal

@JNBarchan
Thanks for your suggestions. Yes, you are correct. And yes, I would like to handle the situation before the actual move has happened. And it does work like a charm when I handle the mouseEvent. The problem with that, though, is that when I select two items and drag them, mouseEvent() is only called for the one that actually is under the mouse cursor. So that one gets constrained, but the other one still can happily move wherever it wants.

I took this this restraining method from the QT documentation (http://doc.qt.io/qt-4.8/qgraphicsitem.html#itemChange). I'm now wondering if it has something to do with the fact that I'm using Python, because it is inherently slower than C++.

JonB

@Oatmeal
Although I don't know what your exact code is, I should be most surprised if it were any noticeably slower than the corresponding C++. Python is not bad at speed, but in any case a few lines of code at the Python side is neither here nor there: the time will be spent in the Qt code it calls/is called from in a UI context.

Oatmeal

@JNBarchan
I posted my exact code at the beginning (between the lines of hash tags), but I admit I didn't do a good job at getting the web page to display it well.

JonB

@Oatmeal

but I admit I didn't do a good job at getting the web page to display it well.

:) When posting a block of code here, use the </> "toolbar" button to cause to surround the whole code. It puts in:
```
(triple-backtick) markers on a line of their own at the start & end of the whole block, and does not rely on you indenting each line with spaces!

Oatmeal

@JNBarchan
Thanks. I edited my post to make the code look prettier.

Oatmeal

Come on, guys, I wouldn't have thought that I have discovered an unsolvable problem with Qt or that I am trying to do something so far out of the ordinary. I'm sure that if somebody versed in Qt threw the above code in an editor and ran it, they would find out in the blink of an eye what I am doing wrong.

selimnar

@Oatmeal I guess you already solved your issue since 9 months passed but I experienced same issue today and solved it eventually so I want to share it anyway. Instead of using below code
self.setFlag(QGraphicsItem.ItemIsMovable, True)
self.setFlag(QGraphicsItem.ItemIsSelectable, True)
self.setFlag(QGraphicsItem.ItemIsFocusable, True)
self.setFlag(QGraphicsItem.ItemSendsGeometryChanges, True)
using below code did the trick for me
setFlags(QGraphicsItem::ItemIsMovable | QGraphicsItem::ItemIsMovable | QGraphicsItem.ItemIsFocusable | QGraphicsItem::ItemSendsGeometryChanges);