summaryrefslogtreecommitdiffstats
path: root/src/sql/doc/snippets/code
diff options
context:
space:
mode:
authorGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>2023-01-05 03:46:45 +0100
committerGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>2023-01-23 15:51:55 +0100
commitbaa5888807d3db57603398ae7aa27866efdbd711 (patch)
treec7d8801e3a9dfa5de03fb449e6403890bd46dcf4 /src/sql/doc/snippets/code
parent3d8e02152a4c83a45f616dcad6852bc71fc3996d (diff)
Windows: use MSG timestamps for input events
Input events have a timestamp. When dispatching an event through QPA, a platform plugin can either provide it, or QPA will use an internal QElapsedTimer to provide a timestamp. Windows input messages do come with a timestamp already, so we can use that instead of the QPA. The two methods are not equivalent. For instance: for various reasons, Qt does not honor Windows' "double clicked" message, but uses the delta between two mouse events to establish if the second click is actually a double click. Now suppose that the user double clicks on a widget. On the first click, the application does something that freezes it for a bit (e.g. some heavy repainting or whatever). Does the second click register as a double click or not? * If we're using Qt's own timer, the answer is NO; the event is pulled from the WM queue after the freeze, given a timestamp far away from the last click, and so it will be deemed another single click * If we use the OS' timestamps, then the second click will be seen as "close" to the first click, and correctly registered as second click. This reasoning can be extended to many other QPA events, but looks like the APIs for some are missing (e.g. enter events), so I'm not tackling them here. Task-number: QTBUG-109833 Change-Id: I149361a844feac86cafa885c109a1903b1e49545 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Diffstat (limited to 'src/sql/doc/snippets/code')
0 files changed, 0 insertions, 0 deletions