[Development] 回复: QPushButton: drag and drop

[Zhang JiDe]

I agree that we should fix this, but it's not as simple as passing the mouseReleaseEvent to the QPushButton, but we should make sure that for a QWidget, whatever happens, the mouse press and release are paired, always notify the mouse release to the QWidget of pressed target. If adding a new event to it will make things complicated, I suggest adding a new item for MouseEventSource, such as: MouseEventSynthesizedByUngrab, which is like to XCB_NOTIFY_MODE_UNGRAB, judge the source of QMouseEvent in QPushButton, if it is MouseEventSynthesizedByUngrab, do not trigger clieck, and update the UI.
________________________________
发件人: Development <development-bounces at qt-project.org> 代表 Volker Hilsheimer <volker.hilsheimer at qt.io>
发送时间: 2022年6月4日 11:44
收件人: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>; development at qt-project.org <development at qt-project.org>
主题: Re: [Development] QPushButton: drag and drop

> 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

_______________________________________________
Development mailing list
Development at qt-project.org
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopment&data=05%7C01%7C%7C6030caf001bc42d9ee0808da461fe54a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637899400048996725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FeoHpdNSH2T3DV2PrXZmMpXzA5kxPzXzMta1J6BZA3I%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220606/5da4bb8b/attachment-0001.htm>