> On 2022 Jun 3, at 23:05, Volker Hilsheimer <volker.hilshei...@qt.io> wrote: > > This is of course a special case, but it shows that we can’t just start > delivering MouseButtonRelease events to widgets when a drag operation > finishes, because they would suddenly execute mouseReleaseEvent code in a > state in which they don’t expect it to.
This might resemble the case when a TouchCancel event is sent: it means the receiver should be un-pressed, undo whatever was done on press, and don’t react otherwise (e.g. a Button does not get clicked, it’s just not pressed anymore). And it’s inconsistent that we only have TouchCancel, but don’t follow this pattern for other device types. Maybe we could rename it to PointerCancel (have both names point to one value in Qt 6, deprecate the enum name TouchCancel, and remove it in Qt 7). Maybe QWindow::startSystemMove() should result in the platform plugin sending a PointerCancel event when it succeeds in taking over the mouse? Because that’s a case where Qt handles the mouse press, maybe some of the moves (up to the drag threshold), and then the platform takes over handling the rest of the moves and the release. I didn’t dig too deep lately into DnD or startSystemMove() or the exact scenarios when TouchCancel events are sent, but there’s a half-baked idea anyway, that in all these cases the original grabber needs to be told that it will not be receiving any more updates. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
