38806273e5
event()->device() was the most common use case anyway. The idea that the "parent" of a QEventPoint is the QPointerEvent interferes with the ability to copy and move event objects: the parent pointers are dangling unless we use the QPointerEvent subclass destructors to set the points' parents to null. Since there is no move constructor, even returning a QEventPoint from a function by value results in destroying the temporary instance and copying it to the caller's space. So the parent pointer is often useless, unless we do even more work to maintain it when the event moves. If we optimize to avoid copying QEventPoints too much (and perhaps enable exposing _mutable_ points to QML) by storing reusable instances in QPointingDevice (which is the current plan), then the actual parent will no longer be the event. Events are usually stack-allocated, thus temporary and intended to be movable. Change-Id: I24b648dcc046fc79d2401c781f1fda6cb00f47b0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> |
||
|---|---|---|
| .. | ||
| image | ||
| itemmodels | ||
| kernel | ||
| math3d | ||
| painting | ||
| qopengl | ||
| qopenglconfig | ||
| qvulkan | ||
| rhi | ||
| text | ||
| util | ||
| .prev_CMakeLists.txt | ||
| CMakeLists.txt | ||
| gui.pro | ||