Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
6.3.0 Feature Freeze
-
None
-
8
-
6852c20502 (qt/qtbase/dev) 6852c20502 (qt/tqtc-qtbase/dev)
-
Team Two Foundation Sprint 49
Description
There are two uses of QMutableEventPoint:
- copying a QEventPoint's properties and allowing manipulation. In this case, the object is an actual QMutableEventPoint, and it's use is ok, albeit made complicated by missing conversions from and to QEventPoint.
- casting a QEventPoint to QMutableEventPoint in order to manipulate properties that QEventPoint doesn't provide getters for. This usage depends on UB (invalid casts and invalid member calls d/t object type mismatch), and we must get rid of it.
My current thinking is that it's ok to have a QMutableEventPoint, as a private subclass of QEventPoint, with explicit conversions from and to QEventPoint, so as to not require casting. At the same time, like mentioned in QTBUG-99563 for QMutable*Event, we could have static setter methods that can act directly on QEventPoints.
I have a working prototype that implements the above two ideas, but the main issue here is the unclear sharing behaviour: most setters neither detach() nor check for d == nullptr, with the exception of setTimestamp() and updateFrom(), which conditionally and unconditionally detach, respectively. This could be handled by only allowing move conversion from/to QEventPoint, which is probably the way to go for the first iteration.
Attachments
Issue Links
- is duplicated by
-
QTBUG-124134 Mouse events that are synthesized from touch events do not inherit from QMouseEvent and casting to QMouseEvent crashes application
-
- Closed
-
- relates to
-
QTBUG-99563 The QMutable*Event construct is Undefined Behaviour
-
- Closed
-
-
QTBUG-133321 Provide QEventStorage to allow storing QEvent subclasses without exposing the copy operations as public API
-
- Open
-