[Development] QPushButton: drag and drop

[Volker Hilsheimer]

> On 4 Jun 2022, at 00:41, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
> 
> Il 04/06/22 00:39, Shawn Rutledge ha scritto:
>> 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).
> 
> This is an interesting idea (either a new event or a flag on the release event to know that "something else" has happened in the meanwhile, so it shouldn't act as if it was a real release).


Yes, adding a new “cancel” event that informs a widget that it has lost the mouse grab could be an idea. We have QEvent::WindowBlocked/WindowUnblocked for instance to inform a window that it is about to get blocked/unblocked by a modal dialog.

I don’t think we deliver those events when the modal drag’n’drop starts (since it’s not a modal dialog blocking the window, which is the specific documentation of these event types). And since usually (at least when I refer to the widgets we have in Qt) the widget itself is responsible for starting the modal drag’n’drop, it knows exactly when the operation starts and ends. For that usage pattern, a new event adds no new information.

Adding a new event type allows us to dispatch drag-start/end information to the source widget (or all widgets? the entire window hierarchy?) without risking that we execute existing event handlers like mouseReleaseEvent. But then for Laszlo’s problem, he’d have to implement a new event handler just to call setDown(false), when he can do that right now already in the existing event handler form where he calls QDrag::exec.

Perhaps it’s useful in situations where an application calls QDrag::exec (or QDialog::exec) in response to a signal (such as QAbstractButton::pressed), instead of overriding event handlers. But then, would we expect that all widgets handle that event to cancel their interaction and reset their state (there is no sensible default implementation)? That would add a lot of state handling logic, to every widget class, for many of the signals they emit, just to support what seems to me like an extremely rare use case.

Volker