Override cursor handling in spinbox and autocommit is buggy ...

[markotoplak]

... at least in theory: I did not try to reproduce the bug, I just see it in code. We fall into the same trap as this guy: https://stackoverflow.com/questions/66185831/pyqt5-how-to-restore-the-default-cursor-after-multiple-overrides

Whenever we override an application-wide cursor, these go onto a stack. For example, if anything overrides the cursor while you are dragging in the spinbox, then after drag the overridden cursor will not be restored.

I do not see a safe use of override cursors. As a hack, restores could become something like the following, which guarantees that the default cursor will always be restored.

while QApplication.overrideCursor() is not None:
   QApplication.restoreOverrideCursor()

To use it, we would also need to be sure that QApplication.restoreOverrideCursor() does crash if the current stack is empty (because this code could clean someone else's cursor).

So I'd avoid override cursors completely. SpinBoxes could probably be rewritten to capture the mouse and then use .setCursor on themselves.

[irgolic]

while QApplication.overrideCursor() is not None:
   QApplication.restoreOverrideCursor()

Sure, we can do that. In the rare possibility that we write cursor overrides that trigger while another widget is focused, that will save us.

So I'd avoid override cursors completely.

They're very valuable from a UX perspective, and with the fix you presented, I don't see what threat they pose.

SpinBoxes could probably be rewritten to capture the mouse and then use .setCursor on themselves.

You're right, that would be a great solution. The behavior now works fine, but if the spinbox were to capture the cursor and not let it escape, the drag functionality wouldn't be limited to just your screen size. The cursor should still be overridden.

[markotoplak]

Sure, we can do that. In the rare possibility that we write cursor overrides that trigger while another widget is focused, that will > They're very valuable from a UX perspective, and with the fix you presented, I don't see what threat they pose.

I wrote sloppily: I do agree that cursor changes are useful, therefore we should make sure they are correct. Wherever I see QApplication.setWhatever I think of problems. We can never know what code runs in the meanwhile. I'd avoid it if there is another way.

That spinbox is the smaller problem though: the autocommit is worse. :) Just writing the issue here so that we become more aware of similar issues...