|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There doesn't seem to be any reason users will need to query tablet
devices by their IDs, because every event comes with a complete
instance already, and we have QInputDevice::devices() to list them all.
QPointingDevicePrivate::tabletDevice() can create a new instance if a
matching one is not found (and complains about that); it's intended
for use in QtGui, as a way to find the device if it was not part of the
QWSI event. Now it sets the parent of those auto-created instances
to QCoreApplication to avoid a memory leak.
On the other hand, queryTabletDevice() is intended for use in platform plugins
that need to check whether an instance exists; but they will take care
of creating new instances themselves, and thus have more control over the
parent and the details being stored. Now that the systemId can also be given,
the search is more likely to have a unique result, on window systems
that provide device IDs.
Rename id() to systemId() to clarify that it's a system-specific unique
device ID of some sort, not the same as the uniqueId that a stylus has.
However it seems that in practice, this will often be 0; so clarify that
if it's not unique, QInputDevicePrivate::fromId() and queryTabletDevice()
may not always find the right instance.
Clarify the function usage via comments.
Change-Id: I82bb8d1c26eeaf06f07c290828aa17ec4a31646b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
|