summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/windows/qwindowspointerhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Windows: Remove legacy mouse handlingOliver Wolff2024-06-121-3/+10
| | | | | | | | | | | | | | Pointer handling API was added in Windows 8. As we no longer support Windows 7, we can make mouse handling code easier to read/maintain be removing the legacy implementation. [ChangeLog][Windows] Legacy mouse handling has been removed. It is no longer possible to enforce legacy mouse handling by passing "-nowmpointer". Pick-to: 6.8 Change-Id: I58387471999a371fd20c644abbcf855e192d220b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Windows: use MSG timestamps for input eventsGiuseppe D'Angelo2024-04-031-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. This commit reverts ade96ff6446d4b0977d4e5f03b96b77ff8223b8b. Task-number: QTBUG-109833 Task-number: QTBUG-122226 Change-Id: I5f3fba029b44c618ef622bacdc4bcc3928e04867 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
* Windows QPA: Fix wheel events when using -platform windows:reverseFriedemann Kleint2023-11-091-7/+7
| | | | | | | | | | | | | Wheel events in WM_POINTER messages use global coordinates. Move the code doing the RTL correction into the local coordinates branch. Fixes: QTBUG-117499 Task-number: QTBUG-28463 Pick-to: 6.6 6.5 Change-Id: I10e965da9e9660985eaa2681fcf780b5388299a2 Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Timothée Keller <timothee.keller@qt.io>
* Implement QWindowsKeyMapper in terms of QPlatformKeyMapperTor Arne Vestbø2023-10-091-4/+8
| | | | | Change-Id: I060ca9613d49bb85a2cf8d4f808b2b5b1c0bdcd5 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Send LeaveEvent as reaction to WM_POINTERLEAVE to reset hover statesMatthias Rauter2023-06-161-0/+2
| | | | | | | | | | | | | | Currently items can get stuck in a hovered state when all fingers are lifted from a touchscreen. This is because we don't react to the WM_POINTERLEAVE event from Windows. With this patch we translate a WM_POINTERLEAVE event to a LeaveEvent to remove the hover state from QtQuick items. Fixes: QTBUG-62912 Pick-to: 6.5 6.6 Change-Id: I8a6fb6b7ec77457854a75e20277565d1eb89bab6 Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QWSI: Remove handleFrameStrutMouseEvent in favor of handleMouseEvent+typeTor Arne Vestbø2023-03-311-8/+5
| | | | | | | | | | | | | | | The handleMouseEvent function already takes a QEvent::Type, where clients pass in the corresponding mouse press/release/move type. The same applies to the handleFrameStrutMouseEvent. To avoid the chance that clients call these functions with a conflicting event type (handleFrameStrutMouseEvent with MouseButtonPress instead of NonClientAreaMouseButtonPress e.g.), we remove handleFrameStrutMouseEvent altogether and just let clients use the handleMouseEvent function directly with the correct event type. Change-Id: I4a0241c39aedac0d2d8d5163ba05cde72605959c Reviewed-by: Lars Knoll <lars@knoll.priv.no>
* Revert "Windows: use MSG timestamps for input events"Oliver Wolff2023-01-301-10/+10
| | | | | | | | | | | | This reverts commit baa5888807d3db57603398ae7aa27866efdbd711. The change caused breakages in qtdeclarative's auto tests. Current assumption is that we need the system timestamps for other events as well. Reverting now to unblock CI. Fixes: QTBUG-110596 Change-Id: I9583627bc058ff0d6cadfa622eed119fb41ca4a1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Windows: use MSG timestamps for input eventsGiuseppe D'Angelo2023-01-231-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Windows QPA: Remove tablet->mouse synth and fix Drag&Drop with touch/penAndré de la Rocha2022-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch avoids synthesizing mouse messages in the QPA for touch/pen input, and lets the GUI do mouse event synthesis for unhandled touch/pen events, if required, like in other platforms. This requires a workaround to avoid breaking drag and drop with touch/pen (or making it worse). DnD on Windows is based on the DoDragDrop() Win32 API, which does not work with touch/pen input, which in some cases cause a DnD operation started with touch/pen to hang until the mouse is moved. To avoid it we process pointer messages for touch/pen and generate mouse input through SendInput() to trigger DoDragDrop(), which then seems to work as expected. So now we inform QtGui that the Windows platform no longer sends synth-mouse events after tablet events (unsetting the flag added in f931e5e72d4617023bbea46cba2c0d61bb1efa4f); this completes what was attempted in 8ada0633cd58e0608df2e16880f1293286025504. Fixes: QTBUG-106368 Fixes: QTBUG-57577 Fixes: QTBUG-100788 Task-number: QTBUG-77414 Task-number: QTBUG-104594 Pick-to: 6.4 6.3 6.2 Change-Id: I46db3c74be2a95cf2d94ba930398e58dc930d2db Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Windows: bump NTDDI_VERSION to latest version and remove some duplicated codeYuhang Zhao2022-10-241-3/+1
| | | | | | | | | | | | | | | We have NTDDI_WIN10_NI (0x0A00000C) in the Win11 SDK (10.0.22621) so bump the value in Qt (currently 0x0A00000B) to it. And when searching for _WIN32_WINNT/WINVER/NTDDI_VERSION throughout the whole qtbase codebase, I found some duplicated code, mostly leftovers from the legacy time. Replace them with our own windows header can achieve the same effect: we have defined all the necessary macros to unblock the latest features. And place the header at the top most place to include the macros as early as possible. Change-Id: I37d9ac40ca9748208c7b2e89f374eda362dbefd6 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-111-1/+1
| | | | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace, with manual unstaging of the actual definition and documentation in dist/, src/corelib/doc/ and src/corelib/global/. Task-number: QTBUG-99313 Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Apply Q_CONSTINIT where beneficialSona Kurazyan2022-09-011-1/+1
| | | | | | | | | | Applied Q_CONSTINIT to variables with static storage duration, but skipped the POD types with core constant initializers. Task-number: QTBUG-100486 Change-Id: Iaabf824e9cb0f29a405a149912200d4e4b3573c1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Windows QPA: Further cleanup of pre-Win10 codeYuhang Zhao2021-11-241-14/+11
| | | | | | | | | | | | | | | | | Mostly a removal of dynamically loaded Win32 APIs. Since Qt 6's minimum supported platform is Win10 1809 (10.0.17763, code name RS5), all these functions will be available and no need to resolve them at run-time. Things not remove: WinTab functions in "qwindowstabletsupport.cpp". Not my familiar area, so not touch it. Pick-to: 6.2 Task-number: QTBUG-84432 Change-Id: I7ad6c3bc8376f6c0e3ac90f34e22f7628efeb694 Reviewed-by: André de la Rocha <andre.rocha@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Windows QPA: Fix multi-touch support in some devicesAndré de la Rocha2021-11-181-8/+35
| | | | | | | | | | | | | | | | Some multi-touch devices send touch information for each finger using different WM_POINTER messages/frames, instead of a single one with a list of touches, like most devices. This would result in the generation of multiple touch events, which can cause unexpected behavior in applications (the QTouchEvent documentation specifies that it should contain all simultaneous touches). This patch adds a workaround to ensure all simultaneous touches are included in the events, to comply with the expected behavior. Pick-to: 6.2 5.15 Change-Id: I12a2f84b35a6bdd49ee53d25de580c0941a9aea6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Bump WINVER, _WIN32_WINNT and _WIN32_IE to _WIN32_WINNT_WIN10 (0x0A00)Yuhang Zhao2021-11-101-5/+2
| | | | | | | | | | | And bump NTDDI_VERSION to 0x0A00000B (NTDDI_WIN10_CO) at the same time, to unblock the developers from accessing the latest Windows APIs. Pick-to: 6.2 Change-Id: Ifbc28c8f8b073866871685c020301f5f20dc9591 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Windows QPA: Fix mouse event position for QWindows with ↵Friedemann Kleint2021-10-131-1/+6
| | | | | | | | | | | | Qt::WindowTransparentForInput The local position needs to be corrected when the Qt receiver window does not correspond to the native event receiver window. Fixes: QTBUG-97095 Pick-to: 6.2 5.15 Change-Id: Ic9fa3d84b6ee84ae5f8fa2408b0d60e35dbfa328 Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* Windows QPA: Pass device for synthesized touch/tablet eventsFriedemann Kleint2020-11-271-8/+24
| | | | | | | | | | | Add the overloads for mouse events with device/without timestamp and pass the active tablet or touch device. Task-number: QTBUG-88678 Task-number: QTBUG-46412 Pick-to: 6.0 Change-Id: I8695b493540d0cbf50e9c72afe870a7633de3ab9 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Windows QPA: Use a QSharedPointer for the touch deviceFriedemann Kleint2020-10-261-8/+11
| | | | | | | | | | For reasons of symmetry with the tablet devices. As a drive by, give it more distinct IDs. Task-number: QTBUG-46412 Change-Id: Ie667621246b26db6fdda84c5ff2455fe38633cb3 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Windows QPA/WmPointer: Register tablet devices of pointer handlerFriedemann Kleint2020-10-201-13/+55
| | | | | | | Task-number: QTBUG-46412 Change-Id: Ib9b5fd6056a5474ce46c7bde53be7a12c1494611 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Properly deprecate Qt::MidButton in favor of Qt::MiddleButtonEdward Welbourne2020-08-221-7/+7
| | | | | | | | | | | | MidButton had its // ### Qt 5: remove me upgraded to Qt 6 at 5.0; but it dates back to 4.7.0 Replace the many remaining uses of MidButton with MiddleButton in the process. Pick-to: 5.15 Change-Id: Idc1b1b1816673dfdb344d703d101febc823a76ff Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some goals that have hopefully been achieved are: - make QPointerEvent and QEventPoint resemble their Qt Quick counterparts to such an extent that we can remove those wrappers and go back to delivering the original events in Qt Quick - make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl - remove most public setters - reduce the usage of complex constructors that take many arguments - don't repeat ourselves: move accessors and storage upwards rather than having redundant ones in subclasses - standardize the set of accessors in QPointerEvent - maintain source compatibility as much as possible: do not require modifying event-handling code in any QWidget subclass To avoid public setters we now introduce a few QMutable* subclasses. This is a bit like the Builder pattern except that it doesn't involve constructing a separate disposable object: the main event type can be cast to the mutable type at any time to enable modifications, iff the code is linked with gui-private. Therefore event classes can have less-"complete" constructors, because internal Qt code can use setters the same way it could use the ones in QTouchEvent before; and the event classes don't need many friends. Even some read-accessors can be kept private unless we are sure we want to expose them. Task-number: QTBUG-46266 Fixes: QTBUG-72173 Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Windows QPA: Refactor touch device creationFriedemann Kleint2020-07-031-24/+27
| | | | | | | | | | | | | | | | | | | | | There was duplicated code in QWindowsMouseHandler::ensureTouchDevice() and QWindowsPointerHandler::ensureTouchDevice() which caused deprecation warnings since the setters of QInputDevice were deprecated. Join the 2 functions into a single creation function and add simple getters and setters. Fix deprecation warnings: qwindowscontext.cpp:357:108: warning: 'void QPointingDevice::setCapabilities(QInputDevice::Capabilities)' is deprecated: Use the constructor qwindowsmousehandler.cpp:132:97: warning: 'void QPointingDevice::setType(QInputDevice::DeviceType)' is deprecated: Use the constructor qwindowsmousehandler.cpp:136:41: warning: 'void QPointingDevice::setCapabilities(QInputDevice::Capabilities)' is deprecated: Use the constructor qwindowsmousehandler.cpp:137:49: warning: 'void QPointingDevice::setMaximumTouchPoints(int)' is deprecated: Use the constructor Change-Id: Iab5385e84d600e45b60f38225175f25ef043c3eb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: André de la Rocha <andre.rocha@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-32/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have seen during the Qt 5 series that QMouseEvent::source() does not provide enough information: if it is synthesized, it could have come from any device for which mouse events are synthesized, not only from a touchscreen. By providing in every QInputEvent as complete information about the actual source device as possible, we will enable very fine-tuned behavior in the object that handles each event. Further, we would like to support multiple keyboards, pointing devices, and named groups of devices that are known as "seats" in Wayland. In Qt 5, QPA plugins registered each touchscreen as it was discovered. Now we extend this pattern to all input devices. This new requirement can be implemented gradually; for now, if a QTWSI input event is received wtihout a device pointer, a default "core" device will be created on-the-fly, and a warning emitted. In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when multiple devices were in use simultaneously. Now that each event identifies the device it came from, this hack is no longer needed. A stub of the new QPointerEvent is added; it will be developed further in subsequent patches. [ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer to an instance of QInputDevice, or the subclass QPointingDevice in case of mouse, touch and tablet events. Each platform plugin is expected to create the device instances, register them, and provide valid pointers with all input events. If this is not done, warnings are emitted and default devices are created as necessary. When the device has accurate information, it provides the opportunity to fine-tune behavior depending on device type and capabilities: for example if a QMouseEvent is synthesized from a touchscreen, the recipient can see which touchscreen it came from. Each device also has a seatName to distinguish users on multi-user windowing systems. Touchpoint IDs are no longer unique on their own, but the combination of ID and device is. Fixes: QTBUG-46412 Fixes: QTBUG-72167 Task-number: QTBUG-69433 Task-number: QTBUG-52430 Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Avoid initializing QFlags with 0 or nullptr in further casesFriedemann Kleint2019-11-221-1/+1
| | | | | | | | | Amends qtbase/af2daafde72db02454d24b7d691aa6861525ab99. Where applicable, port over to member initialization, thus also fixing nullptr warnings. Change-Id: Iaaf2dbbbcf2952253390b8839fd15a1b17be32c0 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Merge remote-tracking branch 'origin/5.13' into 5.14Qt Forward Merge Bot2019-11-061-1/+3
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/features/mac/default_post.prf src/corelib/tools/qsimd_p.h src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm util/qfloat16-tables/gen_qfloat16_tables.cpp Change-Id: If48fa8a3bc3c983706b609a6d3822cb67c1352a4
| * Query the mouse buttons initially in case the middle button was usedAndy Shaw2019-11-031-1/+3
| | | | | | | | | | Change-Id: I99a3ef598bdaaba1afb6bf6521d1ceafcc9b603c Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-07-171-5/+8
|\| | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qlogging.cpp src/gui/painting/qtextureglyphcache_p.h src/gui/text/qfontengine.cpp src/widgets/widgets/qlineedit.cpp Change-Id: Ic8798538df466b7141caa8bbf1fb7605eb56be37
| * Windows QPA: Fix handling of mouse messages synthesized by the OSAndré de la Rocha2019-07-111-4/+7
| | | | | | | | | | | | | | | | | | | | | | The old handler only marked mouse events associated with mouse messages synthesized by the OS with Qt::MouseEventSynthesizedBySystem when these messages resulted from touch screen, not tablet input. Quick seems to depend on this behavior. Fixes: QTBUG-76617 Change-Id: Ib863d73ae9325f9a19d8a175817fef4e82f7df0b Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
| * Windows QPA: Fix Wheel event coordinatesAndre de la Rocha2019-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | In some cases, the wheel event coordinates would be incorrect, as the local coordinates were being determined relative to one window and the event being sent to another window, possibly incorrect. Fixes: QTBUG-75820 Change-Id: I4c3c4c6c4688bd9232d67ce4052d24365f6aea3a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-06-141-1/+4
|\| | | | | | | | | | | | | | | | | | | Conflicts: qmake/generators/makefile.cpp qmake/generators/unix/unixmake2.cpp src/corelib/thread/qthread_unix.cpp tests/auto/corelib/tools/qsharedpointer/tst_qsharedpointer.cpp Change-Id: I1df0d4ba20685de7f9300bf07458c13376493408
| * Windows QPA: Optimize code that gets window under pointerAndre de la Rocha2019-05-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | It's not necessary to call QWindowsScreen::windowAt() for every mouse message received, but only when the mouse is captured, like it's done in the legacy mouse handler. Change-Id: Ib1035921291d22a32dfa3a619815a3f4ff9b3622 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Windows QPA: Fix clang warnings about repetitive type namesFriedemann Kleint2019-06-131-6/+6
| | | | | | | | | | | | | | | | | | | | Fix warning like: warning: use auto when initializing with new/reinterpret_cast to avoid duplicating the type name [modernize-use-auto] Change-Id: Ieb7f052919173f6923e68de9f9e849dee45e36e7 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* | Windows QPA: Use nullptr consistentlyFriedemann Kleint2019-05-281-1/+1
| | | | | | | | | | | | | | | | | | Change-Id: I09297e34bd62359e31c483199ade1d7a0baf7195 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devFriedemann Kleint2019-05-271-4/+33
|\| | | | | | | Change-Id: Ia279fc4a8226626041c772902a07b2f90f37b53b
| * Windows QPA: Fix QWheelEvent::buttons() after click on title barAndre de la Rocha2019-05-181-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the left or right mouse buttons are pressed over the window title bar a WM_NCLBUTTONDOWN/WM_NCRBUTTONDOWN message is received. But when the button is released, no corresponding UP message is received, but only a WM_NCMOUSEMOVE or WM_MOUSEMOVE. This makes the internal mouse button state stored in QGuiApplication get out of sync with the actual state, resulting in an incorrect button state being used in QWheelEvent. This patch detects the button release condition and generates the missing release event. Change-Id: I6dd9f8580bd6ba772522574f9a08298e49c43e61 Fixes: QTBUG-75678 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Windows QPA: Fix RTL window title barsFriedemann Kleint2019-05-221-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a platform option to the plugin (-platform windows:reverse) that enables reverse mode. It sets WS_EX_LAYOUTRTL on RTL windows, forces normal orientation on all HDCs created for the window, fixes ClientToScreen()/ScreenToClient() accordingly and transforms mouse events. [ChangeLog][Platform Specific Changes][Windows] It is now possible to enable RTL mode by passing the option -platform windows:reverse. Fixes: QTBUG-28463 Change-Id: I4d70818b2fd315d4e8d5627eab11ae912c6e77be Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io> Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-05-131-0/+3
|\| | | | | | | | | | | | | Conflicts: src/corelib/tools/qstring.cpp Change-Id: I81dbf90fc936c9bf08197baefa071117bddb1c63
| * Fix generation of Leave events when using tablet devicesDmitry Kazakov2019-05-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When both mouse and tablet events are handled by QWindowsPointerHandler, m_currentWindow variable is shared among the two event streams, therefore each stream should ensure it does equivalent operations, when changing it. Here we should subscribe to the Leave events, when we emit Enter event from the inside of the tablet events flow. Without whis subscription, the cursor may stuck in "resize" state when crossing the window's frame multiple times. Change-Id: I88df4a42ae86243e10ecd4a4cedf87639c96d169 Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* | Prefix textstream operators with Qt::Lars Knoll2019-05-021-10/+10
|/ | | | | | | As the non prefixed variants are deprecated Change-Id: I2ba09d71b9cea5203b54297a3f2332e6d44fedcf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Fix QTabletEvent::uniqueId() when Qt uses WinInkv5.12.3Dmitry Kazakov2019-04-091-6/+6
| | | | | | | | | | | | | | | A new 'pointerId' is assigned to the stylus every time it enters tablet's proximity. But applications expect this ID be constant, at least during one application run. Therefore, it needs to use 'sourceDevice' instead. Basically, WinInk doesn't have an ability to distinguich two different styluses connected to the same tablet. We cannot do anything about it, it is supported only in WinTab. Task-number: QTBUG-74700 Change-Id: I8328f1e5102b037b370082e69e965ab68b487882 Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* Windows QPA: Fix mouse button reported in non-client eventsAndre de la Rocha2019-04-081-2/+21
| | | | | | | | | | | | | The current mouse buttons state was being retrieved from WPARAM for all mouse messages. However, for non-client messages this parameter contains unrelated information, which resulted in non-client events reporting incorrect button state. Changing it to retrieve state using GetAsyncKeyState() for non-client messages, like in the legacy mouse handler implementation. Fixes: QTBUG-74649 Change-Id: Ia246164208707072e584dd521697e9d31d3e65ad Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: Handle mouse input using legacy messagesAndre de la Rocha2019-02-121-329/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change reverts to using legacy mouse messages when handling mouse and touchpad input, while using pointer messages to handle touchscreen and pen input. The use of pointer messages to handle everything, added in 5.12.0, caused issues in some particular cases, due mainly to differences in behavior or bugs in the pointer messages, which required workarounds in the Windows QPA, which didn't work well in all cases and led to additional issues. For instance, DoDragDrop() does not work when called by pointer (or touch/pen) handlers, but only after OS-synthesized legacy mouse messages are generated. Also, in some cases pointer messages for mouse movement are generated as non-client for client area events. Modal loops like the ones in window resize/move and menu handling caused some issues with pointer messages, as well. Also, we have to handle the OS-synthesized legacy mouse message generated for touch and pen. Ignoring them while letting the gui layer synthesize mouse events for touch/pen may break Drag and Drop by triggering DoDragDrop() before legacy messages, which can result in a hang inside the DoDragDrop() modal loop. This change should fix most regressions related to pointer messages, while keeping the enhancements in pen and touch input. Fixes: QTBUG-73389 Fixes: QTBUG-72624 Fixes: QTBUG-72801 Fixes: QTBUG-73290 Fixes: QTBUG-72458 Fixes: QTBUG-73358 Fixes: QTBUG-72992 Change-Id: I919f78930d3965270ef2094401e827ab87174979 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: handle pointer messages received during a drag and dropAndre de la Rocha2019-01-281-15/+0
| | | | | | | | | | | It seems the pointer message handler was skipping the handling of touch and pen messages during a drag and drop operation, preventing the generation of events that quick was expecting and triggering a crash inside MouseArea. Fixes: QTBUG-73120 Change-Id: I2921e38dd7e44846607e6c614d7393cfa5664c69 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: Support "press and hold for right-clicking"Andre de la Rocha2019-01-141-15/+38
| | | | | | | | | | | | | Windows sends a fake WM_RBUTTONUP/WM_RBUTTONDOWN when the user presses and holds the pen/finger on a tablet/touchscreen, e.g., in order to show a context menu. Windows only sends already synthesized legacy mouse messages for this condition, instead of anything detectable in the pointer messages. So we need to handle these legacy messages in the Windows QPA. Task-number: QTBUG-36162 Change-Id: Ia93c423601e2e8a8baac3f9b7791bf8a3113885a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: Fix mouse pointer capture and Enter/Leave eventsAndre de la Rocha2019-01-031-52/+133
| | | | | | | | | | Qt expects the platform plugin to capture the mouse on any button press and keep it captured until buttons are released. The missing capture logic was causing extra Enter/Leave events to be generated. Change-Id: I5a78ea600374701c740f395b38ba5abd51f561d8 Fixes: QTBUG-72600 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: Avoid duplication of mouse eventsAndre de la Rocha2019-01-021-29/+0
| | | | | | | | | | | | | | | The code being removed was added as a workaround to support the use of QCursor::setPos() with unit tests. This function was used to move the Windows mouse cursor, internally calling SetCursorPos(), which generates only WM_MOUSE* messages, bypassing the pointer messages. However, the workaround had the unintended effect of generating duplicated mouse events for normal mouse movement, which caused issues like the one described by QTBUG-70974. However, it seems the tests are no longer depending on it, allowing it to be removed. Fixes: QTBUG-70974 Change-Id: Iaf0d64c73951ab1b660e9bb90e7ee009e53fbd3a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: Fix touch message queue handlingAndre de la Rocha2018-12-121-0/+8
| | | | | | | | | | | | | In the handling of pointer messages for touchscreen we use a queue that is flushed when mouse messages synthesized by Windows are received. However, these fake mouse messages should be otherwise ignored. Their handling was causing issues with PointHandler in QtQuick. This change fixes the part of QTBUG-71431 that causes a single touch drag to behave unexpectedly with PointHandler. Task-number: QTBUG-71431 Change-Id: Iccdd554876f411bce2dd1f922a3d889e61b7bb1c Reviewed-by: Miguel Costa <miguel.costa@qt.io>
* Merge "Merge remote-tracking branch 'origin/5.12.0' into 5.12" into ↵Liang Qi2018-12-071-1/+4
|\ | | | | | | refs/staging/5.12
| * Merge remote-tracking branch 'origin/5.12.0' into 5.12Qt Forward Merge Bot2018-12-051-1/+4
| |\ | | | | | | | | | Change-Id: I54b4c14bed5150d3034ac87907a09254fd78face
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-29 05:12:58 +0000