| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a touch event with a second touch pressed is delivered inside
graphicsview, we should combine it with the closest touch point even if the
item under the second touch is not direct ancestor or child of the first
touches' target item.
So adding a second touch inside the item's bounding rect will send a
TouchUpdate event to the item instead or starting a new touch event sequence.
Task-number: QT-3795
Reviewed-by: Bradley T. Hughes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QGraphicsItem
After propagating QEvent::TouchBegin, if there is no item that has
accepted and handled the event, we must remove the touch point from our
data structures.
In this situation, QGraphicsScene will ignore the TouchBegin, as will
QGraphicsView, and QApplication will respond by not sending any more
touch events to the view/scene/item. This means our logic for handling
TouchPointReleased points will never be called (and the QGraphicsScene's
itemForTouchPointId and sceneCurrentTouchPoints state will be
incorrect).
Reviewed-by: Denis Dzyubenko
Reviewed-by: Marius Storm-Olsen
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use QWeakPointer to bail out early if a widget is deleted while we are
delivering/propagating a TouchBegin event.
In QGraphicsScene, we need to make sure that we clear the scene's
active touch points for items that are removed from the scene. This
allows us to detect when an item is removed during TouchBegin event
delivery/propagation. Unlike QWidget, propagation continues since we
use a hit-test instead of the item's hierarchy for propagation.
Task-number: QTBUG-6654
Reviewed-by: bnilsen
|
|
|
|
|
|
|
|
| |
QGrahpicsItem behaves similarly to QWidget; if the TouchUpdate or
TouchEnd event is ignored, then the event sent to the view and scene
will also be ignored.
Reviewed-by: Trust me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
| |
Since QTouchEvents can also be sent to QGraphicsItems, we want to test
that it actually works.
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Commercial license headers belong in source packages only. The repo
must have the pre-release license headers.
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
| |
Add 2 basic tests that, when faced with multiple touch points, make sure
we send multiple touch events on TouchScreen devices, but only one event
on TouchPads.
|
|\ |
|
| |
| |
| |
| |
| | |
Update the auto test for QTouchEvent to make sure the pressure is set to 1 for
Pressed/Moved/Stationary, but for 0 for Released.
|
|/
|
|
|
|
|
|
|
| |
This enum indicates what kind of device generated the touch event
(TouchScreen or TouchPad). We use this information to control how touch
events are sent, specifically we restrict touch events to a single
widget/QGraphicsItem on touch-pads, since there is no direct
relationship between the physical touch location on the pad and the on-
using the touch-pad).
|
|
|
|
|
|
|
|
|
| |
This introduces normalizedPos(), startNormalizedPos(), and
lastNormalizedPos() in QTouchEvent::TouchPoint, and must be set by the
implementation before being fed into Qt.
We are assuming and hoping that these functions will make it easier to
implement certain types of gestures (especially on a touchpad).
|
|
|
|
|
|
| |
That way the widget local positions will not be the same as the screen
coordinates. (I missed a bug in QTouchEvent::TouchPoint because of this
coincidence in the test).
|
| |
|
|
|
|
|
|
| |
coordinates for widgets
Previously these returned empty/invalid values.
|
|
|
|
|
|
|
|
|
| |
the API for these 2 classes is identical, the implementation is almost
identical, they share the same data structures, so bite the bullet and
merge them.
this means we go back to using screenPos() instead of globalPos()
again
|
| |
|
|
|
|
|
| |
this makes sure that we get the proper start/last position maintenance
and global->local translation.
|
|
|
|
| |
Qt::WA_AcceptTouchEvents
|
|
|
|
|
| |
The mask isn't used and changing it doesn't do anything, so this is
just a cosmetic/clarification change.
|
| |
|
| |
|
|
|
|
|
| |
test that sending the TouchBegin to this widget both succeeds and
accepts the event
|
|
|
|
| |
the event is accepted by default, but no handled
|
|
start off by testing basic behavior:
1. touch events are disabled by default
2. touch events are automatically accepted when enabled
|