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
f931e5e72d); this completes what was
attempted in 8ada0633cd.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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>
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>
Pointer messages should not be handled when we are inside a move/resize
modal loop. DefWindowProc() should handle this case instead.
Fixes: QTBUG-72078
Change-Id: I5ad7283bcf0cfe0ff7d21cf5640270c361b8ad8d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This issue was caused by the workaround added to fix QTBUG-70887.
Certain events like the initial touch down do not generate mouse
messages after the pointer messages (but only touch messages) and
should not be postponed by the pointer handler.
Fixes: QTBUG-71775
Change-Id: I7b64ae4d422f6a4c1bb465ce5f8255e85640dab1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This change fixes building Qt with the -no-feature-tabletevent configure
option by disabling handling of pointer messages associated with tablet
events within the pointer message handler.
Fixes: QTBUG-71774
Change-Id: Icb47a39793edb9a0f87c07c656b6ea6573d5f947
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This issue was caused by missing logic in the implementation of the
pointer message handler, necessary to support "click to focus" for
native child windows.
Fixes: QTBUG-71352
Change-Id: I2e261caa8dfab096647799ec1e7d781bec40654e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The current state of (emulated) mouse buttons was being incorrectly
reported for touchpad events under some conditions. In the handling
of pointer messages, GetAsyncKeyState() was being used to retrieve the
mouse button state. However, it does not seem to work always with all
touchpads. Furthermore, its use is not necessary, since the button
state information comes as a set of flags with the pointer message
itself. This change makes the handler use these flags instead.
Fixes: QTBUG-71470
Change-Id: Ie2e35bd80778ef74db672604a0f2af659785efbf
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It seems some touchpads only send legacy WM_MOUSEWHEEL/WM_MOUSEHWHEEL
messages for 2-finger scrolling, instead of WM_POINTERWHEEL/
WM_POINTERHWHEEL, even after EnableMouseInPointer(TRUE), in spite of
sending the expected pointer messages for normal pointer movement/taps.
This change adds a workaround to handle legacy wheel messages even when
in pointer mode.
Task-number: QTBUG-71257
Change-Id: Ib360051147c4521751a5b91d90fa7657496777fa
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The Qt QPA does not handle native double clicks as such; change the plugin
not to send them.
For Ink, remove the doubleclick detection. For the old code path,
map them to Press.
Fixes: QTBUG-70999
Change-Id: I54b858f9e146bf325a861554d5ef74143db7d2b7
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The Drag&Drop functionality had stopped working with touchscreen/pen
after the WM_POINTER-based input handling was added. The Drag&Drop
functionality internally uses the DoDragDrop() WIN32 call which,
according to Microsoft docs, is not supported for invocation inside
handlers for touch/pen messages, and should be invoked in handlers
for mouse messages that are synthesized by the OS afterwards. The
result was that when DoDragDrop (which is a blocking function with
its own event loop) was called it would hang ignoring all touch/pen
messages until a mouse/touchpad message arrived. This change
implements a workaround for this issue by enqueuing Qt touch/pen
events that would be generated inside the pointer message handler,
and that could start a Drag&Drop operation, and only producing them
after the OS sends the associated mouse messages.
Task-number: QTBUG-70887
Change-Id: Id45e0ecc70358ba250de9b3268856781ed21c9dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The detection of multiple mouse button presses was broken in the new
WM_POINTER-based implementation. The bug was due to the incorrect
assumption that the press/release of a second mouse button (while
another one is held) would also send WM_POINTERDOWN/WM_POINTERUP, while
in fact it sends a WM_POINTERUPDATE with the actual event type given
by pointerInfo->ButtonChangeType.
Task-number: QTBUG-70787
Change-Id: Ib6776ab7f3d0b8eb5e832a0c863a15bde456e0dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
If the hardware produces events faster than the app can consume between
two updates, Windows automatically coalesces them into a single message
with the latest touch/pen pointer state and coordinates, effectively
compressing those events. But the pointer API also supports querying
and retrieving the skipped individual touch and pen frames.
There are cases where keeping all the events generated by the hardware
is desired, especially for pen events where having the most sampled
points available is critical to precisely rendering curves.
Qt already defines application attributes to control event compression
for general high frequency events and for tablet events in particular.
Use them on Windows also to control whether to retrieve skipped frames.
[ChangeLog][Windows] The application attributes AA_CompressTabletEvents
and AA_CompressHighFrequencyEvents are now supported on Windows 8 and
above for touch/pen input, with the same defaults as on X11 (compress
touch events, don't compress tablet events)
Task-number: QTBUG-44964
Task-number: QTBUG-60437
Change-Id: I1b11a043e2d71ee502895971fafb3a46306a89d8
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
These fake mouse events should be synthesized by QtGui, not the QPA plugin,
when the tablet/touch events are not handled by the application and the
Qt::AA_SynthesizeMouseForUnhandledTouchEvents or
Qt::AA_SynthesizeMouseForUnhandledTabletEvents flags are set.
Task-number: QTBUG-47007
Task-number: QTBUG-60437
Change-Id: I4d6d5e6667d245c45a4eb4f3a94db05cf9772f52
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Romain Pokrzywka <romain.pokrzywka@gmail.com>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
André de la Rocha
Yuhang Zhao
Marc Mutz
Sona Kurazyan
Lucie Gérard
Friedemann Kleint
Edward Welbourne
Shawn Rutledge
Qt Forward Merge Bot
Andy Shaw
Dmitry Kazakov
Liang Qi
Romain Pokrzywka