On 06/06/2022 10:49, Zhang JiDe wrote:
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.
Well, whether it's a new event or a new "option" for an existing event, this would still require modifications to pretty much every widget class -- e.g. QPushButton would need to check the release event source in its mouseReleaseEvent, to decide what to do?
I still like an event-driven approach, because I still hope one day that we can kill all the blocking exec() methods in Qt, and QDrag::exec() is one of the hardest to get rid of (and one for which we still don't have a solution in the API).
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
