| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Reviewed-by: Trust Me
(cherry picked from commit ac5c099cc3c5b8c7eec7a49fdeb8a21037230350)
|
| |
|
|
|
|
|
|
|
|
| |
The QGestures will now not be deleted immediatly. QGestureManager waits until all
QGestureEvents are processed and will delete the QGestures afterwards.
Task: QT-4022
Reviewed By: Zeno Albisser
|
|
|
|
|
|
|
| |
When the cachedGestures are cleaned, the Gestures should be removed in all QSets first, before the Delete.
Task: QT-4013
Reviewed By: Frederik Gladhorn
|
|
|
|
| |
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
|
| |
The QWeakPointer was part of a key in a QMap. When the QWeakPointer gets deleted,
the key changes and the sorting of the Map was wrong. That leads to an random crash.
It should be safe not to use QWeakPointer as we remove pointers from the
objectGestures map when a widget or graphicsitem gets destroyed.
Reviewed-by: Denis Dzyubenko
|
|
|
|
|
|
|
|
| |
If there is only one widget which is a toplevel, then gestures were not
delivered to it because we assumed (wrong) that there is at least one child
widget.
Reviewed-by: Frederik Gladhorn
|
|
|
|
|
|
|
|
|
| |
If the user unregisters a recognizer before anyone ever used it we didn't
delete it on application exit.
This fix makes sure we do.
Task: QTBUG-12845
Reviewed-by: Denis Dzyubenko
|
|
|
|
| |
Reviewed-By: Denis
|
|\
| |
| |
| | |
4.7-staging1
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4.7-integration
* '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-2:
Fix compilation: disable -no-feature-* for bootstrapped
QString: Fix severals bugs when comparing with QStringRef
QProgressBar: make accessors const.
Changes: add patch for artificial emboldening
Added static version of QGLFramebufferObject::release().
Fix compilation on WinXP MinGW32;
Add a new qconfig feature GESTURES
|
| | |
| | |
| | |
| | |
| | | |
Merge-request: 535
Reviewed-by: Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com>
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
gestures are re-used per widget / recognizer and in the case
of a gesture getting cancelled we sometimes didn't properly
'start' the gesture on new incoming events since the manager
forgot to mark it as not running.
Add a test case and a one line fix.
Reviewed-by: Denis
Task-number: QTBUG-11076
|
|/
|
|
|
|
|
|
| |
When a gesture recognizer switches from MayBeGesture to Cancelled gesture we
need to reset the state of the recognizer, but do not send any events to the
user.
Reviewed-by: Thomas Zander
|
|
|
|
|
|
|
|
|
|
|
| |
According to users of the api "maybe" timer (that is supposed to cancel
gestures that have stayed in the "MaybeGesture" state for too long) is not
useful and might even harm some gestures, so removing it completely and leaving
it up to the author of a gesture recognizer to make sure the state machine is
implemented properly.
Task-number: QTBUG-9926
Reviewed-by: Thomas Zander
|
|
|
|
|
|
|
|
| |
need to remove a QGesture object pointer from an internal hash when the
widget/graphicsobject gets destroyed.
Task-number: QTBUG-9801
Reviewed-by: Thomas Zander
|
|
|
|
|
|
|
|
| |
Work around the case when we reach QGestureManager indirectly from
QGraphicsObject destructor.
Task-number: QT-3262
Reviewed-by: Thomas Zander
|
|
|
|
|
|
|
|
|
|
|
| |
Another fix for the same problem - we also need to be careful - when ungrabbing
a gesture for the recognizer that has already been destroyed and cleaning up
the QGesture object for it we need to make sure we know it is removed from the
obsolete gestures list so that we won't delete it again in the QGestureManager
detructor.
Task-number: QTBUG-9801
Reviewed-by: Thomas Zander
|
|
|
|
|
| |
Task-number: QTBUG-9801
Reviewed-by: Thomas Zander
|
|
|
|
|
|
|
|
|
| |
If there is no touch input device attached on Windows7, we shouldn't even
bother subscribing to native gesture events.
Task-number: QTBUG-6007
Reviewed-by: Thierry
Reviewed-by: Prasanth
|
|
|
|
|
|
|
|
| |
Moved the gestureManager pointer to a QApplicationPrivate to make sure if
QApplication object is destroyed, QGestureManager pointer is set to zero.
Task-number: QTBUG-7029
Reviewed-by: Thiago
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Now we don't filter some events through the gesture manager and use QMap
instead of QHash, which seem to be a bit faster in our cases.
Reviewed-by: Olivier Goffart
|
|\
| |
| |
| |
| | |
Conflicts:
src/gui/painting/qbrush.cpp
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
|\ \
| |/
| |
| |
| | |
Conflicts:
src/gui/kernel/qwidget_win.cpp
|
| |\ |
|
| | |
| | |
| | |
| | | |
Reviewed-by: paul
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
The option allows to disable native Windows7 gestures since they require the
creation of the native window handle. This partially disabled alien widgets
concept and make window resizing slower and more flickery.
Reviewed-by: Espen Riskedal
|
| |
| |
| |
| |
| |
| | |
Added QGesture objects and gesture recognizers based on touch events.
Reviewed-by: Bradley T. Hughes
|
|/
|
|
| |
Reviewed-by: Bradley T. Hughes
|
|\
| |
| |
| |
| |
| | |
Conflicts:
dist/changes-4.6.0
src/gui/kernel/qevent.h
|
| |
| |
| |
| |
| |
| | |
Changes to the gesture api after the review.
Reviewed-by: Jasmin Blanchette
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By default if the gesture is ignored, only gestures in the started state
are propagated, and accepting a gesture in the started state adds an
implicit grab meaning all the following events in the gesture sequence
will be delivered to that widget. This is similar to the way QTouchEvent
is propagated.
Also added a hint, which specifies if gestures in any state can be
propagated to the widget which has enabled the hint.
Reviewed-by: Thomas Zander
|
| |
| |
| |
| | |
Reviewed-by: trustme
|
| |
| |
| |
| | |
Reviewed-by: trustme
|
| |
| |
| |
| | |
Reviewed-By: Denis
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
There is no reason to use QMap when the key is a pointer.
Reviewed-by: Thomas Zander
|
| |
| |
| |
| |
| |
| |
| | |
When application closes and we haven't deleted the unregistered gestures
and gesture recognizer, we should delete them.
Reviewed-by: Thomas Zander
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When there are several gesture recognizers registered for the same
gesture type, we need to know which recognizer we need to get a state
object for since those QGesture objects are tied to the recognizer that
created them.
Reviewed-by: Thomas Zander
|
| |
| |
| |
| | |
Reviewed-By: TrustMe
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On accepting one gesture Qt can automatically cancel other gestures
that belong to other targets. The policy is normally set to not cancel
any other gestures and can be set to cancel all active gestures in the
context. For example for all child widgets.
Reviewed-By: Denis Dzyubenko
|
| |
| |
| |
| | |
Reviewed-By: trustme
|
| |
| |
| |
| | |
Reviewed-by: Denis Dzyubenko
|
| |
| |
| |
| | |
Reviewed-by: Denis Dzyubenko
|
| |
| |
| |
| | |
Reviewed-by: Denis Dzyubenko
|
| |
| |
| |
| | |
Reviewed-by: Denis Dzyubenko
|
| |
| |
| |
| |
| |
| |
| |
| | |
We shouldn't add several graphicsobject contexts for the same gesture
type when looking for the gesture-enabled QGraphicsObject under a
hotspot.
Reviewed-by: Thomas Zander
|
|/
|
|
| |
Reviewed-by: tom
|