summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qinputdevice.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QInputDevice: Parent default keyboard to core app singletonFabian Kosmale2020-12-041-1/+1
| | | | | | | | | | | | With this we can avoid leaking the QInputDevice which is created when the platform plugin does not provide any. The onwership is solved in a similar way as in the plugins, except that here we have no parent which really fits, so we use QCoreApplication::instance instead. Change-Id: I77a212fb592ba3d5a42b2ecd486763e3b4d3410e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit bc093cd294cbf48eb93b776fc0b927f0a43fa603) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Move QEventPoint and QPointingDeviceUniqueId out of qeventVolker Hilsheimer2020-11-071-3/+1
| | | | | | | | | | | | | | | | | | | qevent.h/cpp are huge already, no need for more classes. Move QEventPoint into new qeventpoint.h/cpp files, and QPointingDeviceUniqueId into qpointingdevice.cpp; the class is already declared in qpointingdevice.h. Move the documentation of QEventPoint APIs next to the implementation, and document all APIs as properties. Add Q_PROPERTY macro where missing. QEventPoint::device needs a workaround of qdoc due to the type being a pointer-to-const; qdoc doesn't know how to tie a \property to it, but documents it correctly. While at it, move the logging category declarations to the header matching the .cpp file where they are defined. Change-Id: I096e609edbb760b5686d577e7fe47eea0807904e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Address API review comments for QInput/QPointingDeviceVolker Hilsheimer2020-11-031-3/+3
| | | | | | | | | | | | | | - Give default constructor an optional parent, as is standard for QObjects - remove default for QObject parent from inheritance constructor - make QPointingDeviceUniqueId comparison inline, remove superfluous inline of hidden friends - mark read only properties as CONSTANT - remove bit-size from enum types; they are stored in the private, and there are just a few instances; no need to save a few bytes at the expense of performance and code cleanliness Change-Id: Ie7d4a587362714e9d3bc41447cef786bbdb382c6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: Fix documentation issues for event and input device classesTopi Reinio2020-09-101-5/+66
| | | | | | | | | | | | | | * Document the new base classes QPointerEvent and QSinglePointEvent, and move relevant documentation to be located under them. * Replace linking to deprecated functions with their new counterparts. * Remove non-existent function and parameter documentation. * Document QEventPoint::State enum. * Prefer \obsolete over \deprecated and fix the usage. * Document the Capabilities enum in the correct location and add docs for the missing enum values. Change-Id: Ic8f2732f2e90ecbf522cd744c601cedcc574825c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Separate QPD::tabletDevice into priv tabletDevice and queryTabletDeviceShawn Rutledge2020-07-071-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add QInputDevice::availableVirtualGeometry()Shawn Rutledge2020-07-061-0/+23
| | | | | | | | | | | | | | | | | | This property tells what part of the virtual desktop the input device can access. This is not a one-to-one mapping with a QScreen, because a Wacom tablet might be configured to access a whole desktop, a whole screen, or an area corresponding to the drawing area of one window; a mouse normally can access the whole desktop (so QScreen::virtualGeometry() would be identical to QInputDevice::availableVirtualGeometry()); a touchscreen normally is mapped to one screen but could be mapped differently; etc. It's possible to find the intersection of the rectangular area with the screen(s) that it overlaps, though. Task-number: QTBUG-78839 Change-Id: I9040e20fb5a3dec8a9a0dd827735826c4c1eea38 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make QDebug operator<< polymorphic for QPointingDeviceShawn Rutledge2020-07-011-0/+4
| | | | | | | | | At least it will look polymorphic by doing dispatch internally. Adding pointingDeviceType avoids the need for qobject_cast, and will probably also be useful in other contexts. Change-Id: I3b6d13765bdf3add9a8208de6f0e98018e40cc42 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Replace "no devices registered" warnings with qCDebugShawn Rutledge2020-06-221-3/+6
| | | | | | | | | | The idea was to keep nagging us to update all the platform plugins to do device registration. But besides being annoying, it would cause test failures if we start adding QTest::ignoreMessage() all over, and then some platforms start doing device registration properly. Change-Id: Ia0fbb64cf86f33532be032ec9eebe6e4ad607f20 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Make QInputDevice::devices() return a QListShawn Rutledge2020-06-171-5/+5
| | | | | | | | | | | There was a decision to use QList consistently in public API, now that it's supposed to perform as well as QVector. Amends 6589f2ed0cf78c9b8a5bdffcdc458dc40a974c60 Task-number: QTBUG-46412 Task-number: QTBUG-72167 Change-Id: I30004792667ee0581a433409ac2e20ffc645e952 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-0/+293
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>