| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If Flickable.flickDirection == HorizontalFlick, then if the accumulated
QWheelEvent::pixelDelta()'s abs(dx) > 2 * abs(dy), clearly the user is
trying to scroll horizontally; otherwise, don't accept the event.
That way the event is allowed to propagate to a parent Flickable that
does allow flicking vertically. Likewise if the nesting is the other
way around, only allow the inner vertical Flickable to accept if the
flicking is actually vertical.
Fixes: QTBUG-57245
Fixes: QTBUG-80236
Pick-to: 6.0
Change-Id: Ieb0bf9310a67210ce7e9fe7a80c88baef2cc7ede
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wheel momentum is great on old "clicky" mouse wheels: they feel really
clunky without this feature. But it's also terrible on most laptop
touchpads. We still aren't generating QWheelEvents with pixel deltas
and ScrollPhase on most platforms (still only on macOS); but eventually
we should. However, those laptop touchpads tend to generate angleDeltas
that are not multiples of 120.
Added logging categories qt.quick.flickable qt.quick.flickable.wheel
and qt.quick.flickable.velocity.
[ChangeLog][QtQuick][Flickable] Flickable now tries to detect whether
you're using a "clicky" wheel on a desktop mouse. A laptop trackpad can
generate QWheelEvent::angleDelta values that are not multiples of 120;
in that case, smooth scrolling with momentum is disabled, to avoid
losing control of scrolling. Set the environment variable
QT_QUICK_FLICKABLE_WHEEL_MOMENTUM_ENABLED=0 to opt out of the old
behavior entirely, or set it to 1 to opt in unconditionally.
Pick-to: 6.0
Task-number: QTBUG-38570
Task-number: QTBUG-56075
Task-number: QTBUG-80720
Task-number: QTBUG-82565
Change-Id: I0da2d31259fa1c79ab217a3fa9e888893fc7b235
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Restore the position of the single event point after event delivery.
Where possible, don't make a localized copy which explicitly shares
its data with the original anyway. Instead, access the original
directly.
Change-Id: I5efa44c336eddeef1a1ab00dc91e2d0f223ed31d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
QMutableTouch/SinglePointEvent can be publicly copy constructed from their
non-mutable counterparts, make use of that.
Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes tst_QQuickListView::touchCancel again. In this scenario, a
TouchCancel is sent, but gets turned into an UngrabMouse for delivery to
the MouseArea which is the current grabber.
We try to avoid calling QQuickWindow::mouseGrabberItem() because it's
too vague a question to ask (which mouse? or did you mean the synth-mouse
during synthesis from a touch or tablet event?); and now it acts different
anyway, because eventsInDelivery.top() is an UngrabMouse, which did not
include a pointer to the QPointingDevice until now. So now we turn
the UngrabMouse event into a QSinglePointEvent so that it's possible to
get exclusiveGrabber() and check that the grabber is not the same
Flickable. (Otherwise, the grabber that's getting ungrabbed is usually
the child receiver item sent to childMouseEventFilter().)
Task-number: QTBUG-86729
Task-number: QTBUG-74679
Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that
has acceptTouchEvents() == true merely fails to accept one touch event,
that does not mean a mouse event should be sent.
Finish changing the default to false: handling touch events is opt-in,
just like handling mouse events; most items don't. And if you opt in,
then you MUST handle touch events, because you will NOT receive mouse
events as a fall-back.
Now that Flickable handles touch, filtering multi-touch events becomes
relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch
when Flickable grabs a stationary touchpoint at the same time as another
touchpoint is pressed, preventing a child PinchArea from reacting.
So there's a new rule: just as we start over with event delivery when a
new point is pressed, QQuickFlickable::filterPointerEvent() should also
not immediately grab when any point is newly pressed; it can afford to
wait, because it's filtering, so it will be able to see if one point is
dragged past the drag threshold later on.
When a parent (such as Flickable) contains only mouse-handling items
(such as MouseArea), the parent should filter the touch event if it is
able (if acceptTouchEvents() returns true). Flickable is now able to.
Filtering parents that are not able to filter touch events can still
filter a synth-mouse event as before. But filtering both must be
avoided: then we would have the problem that Flickable filters a touch
move, sees that it's being dragged past the drag threshold, and sets
d->stealMouse to true to indicate that it wants to steal the _next_
event; then it filters a synth-mouse move, and that's perceived as being
the next event even though it's just a different view of the same event,
so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we
rely on the delay caused by waiting for the next event: the MouseArea is
trying to drag an item and the Flickable wants to flick; both of them
decide on the same event that the drag threshold is exceeded. But
MouseArea calls setKeepMouseGrab() immediately, whereas Flickable
doesn't try to steal the grab until the next event, and then it sees the
keepMouseGrab flag has been set, so it doesn't do it. If Flickable
could filter the same event twice (once as touch, once as synth-mouse),
this logic doesn't work, so it's effectively "more grabby" than
intended. So it works better to have it filter only the actual touch
event, not the synth-mouse that comes after.
When the child has pointer handlers, we need to visit them, and
therefore we should let Flickable filter a touch event on the way.
tst_FlickableInterop::touchDragFlickableBehindButton() depends on this.
[ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must
explicitly call setAcceptTouchEvents(true) to receive QTouchEvents,
and then it must handle them: we no longer fall back to sending a
QMouseEvent if the touch event is not accepted. If it has additionally
called setFiltersChildMouseEvents(true), then it will filter touch
events, not any synthetic mouse events that may be needed for some
children.
Task-number: QTBUG-87018
Fixes: QTBUG-88169
Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent()
and generalized to be able to clone any of the kinds of QPointerEvent
that we're interested in replaying. Now it is used only in
QQuickFlickablePrivate::captureDelayedPress().
Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and
012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip
tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes
from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted.
QEventPoint should always have valid velocity now, so
Flickable no longer has to calculate it for itself.
Removing that became necessary to fix the movingAndFlicking test.
Adds logging categories qt.quick.flickable.filter and .replay.
Fixes: QTBUG-85607
Task-number: QTBUG-83437
Task-number: QTBUG-78818
Task-number: QTBUG-61144
Task-number: QTBUG-88038
Task-number: QTBUG-88138
Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
[ChangeLog][QtQml] The QQmlListProperty callback functions use qsizetype
now as type for the size of a list. This is in line with the containers
that you might use to back the list.
Fixes: QTBUG-88269
Change-Id: Ia38403cb32f241e6c70e1a580dbeff1d6d694331
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Since the Q_ASSERT_X(receiver != this, ...) has been there for a long
time, clearly it never happens in real life. It doesn't happen in any
of our autotests either. So having dead code to handle it is just confusing.
Amends d9d2277fb8e823af8977d6f3aa5cc7ee8213c26a
Change-Id: I69714804e4967cc1a373af67bf4c9a4c169f5738
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
It can also be an UngrabMouse event, a plain QEvent, sent from
QQuickWindowPrivate::onGrabChanged(). So we have to test
isPointerEvent() before casting, rather than asserting beforehand.
Amends 9ce346411eb5bd71ae84647999030ae47c3c544a to fix a crash.
Change-Id: I1d169b4e8c8a58f3736a3d95dfc43fa21e123403
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
...now that we're done with the cherry-pick to 5.15.
Amends 6857ad3e686a5e2b45d28a7f47dca3210608da50.
Task-number: QTBUG-74046
Task-number: QTBUG-85302
Change-Id: I3c2ec091976bcfc170ff58d8fcd226dcdf4c90d2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier we reimplemented the contains() method of ListView to prevent
dragging in an Overlay or Pullback header or footer. But in QQuickWindow
(QQuickWindowPrivate::pointerTargets()), an early check prevents
delivery of pointer events to an item that is clipped and for which
contains() returns false, and also to its children. In that case, the
header or footer no longer responds to a mouse event even if you put a
MouseArea in it.
Reverts 6ad3445f1e159d9beea936b66d267dcaacdc5d6c; reimplemented using
similar logic in a new QQuickListViewPrivate::wantsPointerEvent()
method, overriding QQuickFlickablePrivate::wantsPointerEvent(), which
is now checked in event-handling code in addition to checking the
interactive flag.
Done-with: Wang Chuan <ouchuanm@outlook.com>
Pick-to: 5.15
Task-number: QTBUG-74046
Fixes: QTBUG-85302
Change-Id: I9474f035d26b74ee36c0ac19e45a77de2e694bf1
Reviewed-by: Wang Chuan <ouchuanm@outlook.com>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QEventPoint does not have an accessor to get the QPointerEvent that it
came from, because that's inconsistent with the idea that QPointerEvent
instances are temporary, stack-allocated and movable (the pointer would
often be wrong or null, therefore could not be relied upon).
So most functions that worked directly with QQuickEventPoint before
(which fortunately are still private API) now need to receive the
QPointerEvent too, which we choose to pass by pointer. QEventPoint is
always passed by reference (const where possible) to be consistent with
functions in QPointerEvent that take QEventPoint by reference.
QEventPoint::velocity() should be always in scene coordinates now, which
saves us the trouble of transforming it to each item's coordinate system
during delivery, but means that it will need to be done in handlers or
applications sometimes. If we were going to transform it, it would be
important to also store the sceneVelocity separately in QEventPoint
so that the transformation could be done repeatedly for different items.
Task-number: QTBUG-72173
Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the future, if QQuickFlickable has pressDelay set, and receives a
touch event, we want it to replay the touch after the delay. But in
Qt 5 it can only replay a delayed mouse press, and hacks are in place
to deal with that. We aren't ready to change it all just yet, and
need to keep the autotest working as-is for now.
Task-number: QTBUG-78818
Change-Id: Ib37ccfc2b1b84254f40acac8f8ca8c51c9a88ddf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an intermediate step to get Qt Quick working again after
qtbase 4e400369c08db251cd489fec1229398c224d02b4.
- QQuickEventPoint::id() is no longer unique across devices, because now
eventPoint.event.device tells which specific device the event comes from.
(In Qt 5, we could not yet add the device pointer to QInputEvent.)
- However, MultiPointTouchArea's docs say that each pointId is unique,
and so do the HandlerPoint docs (for similar use cases with PointHandler).
So we still need the same hack using a Qt-specific short device ID
to unique-ify the QEventPoint::id(). Now we use the device index
in QInputDevice::devices() as the short ID.
- Otherwise, we trust QInputDevice::systemId() and QEventPoint::id()
more than before.
- Use QMutable* classes from qevent_p.h to continue using setters
that were in QTouchEvent before, etc. But setTouchPoints() is
not there, so we have to make new event instances in a couple of cases.
- QGuiApplicationPrivate::setMouseEventCapsAndVelocity() and
setMouseEventSource() are gone.
- Use (compiler-written) event copy constructors when possible.
Task-number: QTBUG-72173
Change-Id: I3915dc535ae4c5a81cbf333aba9355f01c420c15
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several event accessors were deprecated in
qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5.
Replacements were generated by clazy using the new qevent-accessors check:
$ export CLAZY_CHECKS=qevent-accessors
$ export CLAZY_EXPORT_FIXES=1
$ ../qt6/configure -platform linux-clang -developer-build -debug
-no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy
$ make
$ cd ../../qt6/qtdeclarative
$ find . -name "*.clazy.yaml"
$ clang-apply-replacements .
Task-number: QTBUG-20885
Task-number: QTBUG-84775
Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AutoFlickDirection and AutoFlickIfNeeded compare the size of the
flickable with the size of the content item. We need to take margins
into account since they might cause the need for scrolling when the
content would otherwise fit.
Fixes: QTBUG-31905
Pick-to: 5.15
Change-Id: I18d073af4c6ffb1b703f5e2b33f616b61e816e56
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Marco Martin <mart@kde.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting the width/height of the content item we need to take
the margins into account. Otherwise for example a left margin of
10 causes the content item to exceed the parent by 10 pixels to
the right. This causes, amongst possibly other issues, misaligned
headers/footers.
Pick-to: 5.15
Change-Id: Ib620bb3be4a4f620b61f14564beb92ceb10ab02f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Marco Martin <mart@kde.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings it in line with the existing convention in this and other
modules, where virtual handlers are named "nounChange"; e.g.
itemChange. Signals are named "nounChanged".
This also allows adding a geometryChanged signal, which would enable
users to listen to one signal for all changes to x/y/width/height.
[ChangeLog][QQuickItem] Renamed geometryChanged to geometryChange
in order to follow existing naming conventions and have consistency
with existing API, such as itemChange.
Task-number: QTBUG-82994
Change-Id: I0547358c796a0047982ccfbf2c38bab952e7a634
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|\
| |
| |
| | |
Change-Id: If7b3f7902eb18d586d8b721e77f4dfedc87cfb9a
|
| |
| |
| |
| |
| | |
Change-Id: I2ac42ded0c2ed4dc3937a57f69109f10b19f9cc7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
QDoc will generate these notes automatically.
Task-number: QTBUG-37355
Change-Id: I8ed058ecbbcc630ad0351f6ce167c3fa61936f6f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/qml/types/qqmlbind.cpp
src/quick/items/qquicklistview.cpp
tests/auto/qml/qqmllanguage/tst_qqmllanguage.cpp
Change-Id: Id6805c13256ad13d5651011e5dd09bba0ec02987
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The issue could be seen when enabling exceptions and running the
following QML code:
Flickable {
id: flickable
anchors.fill: parent
contentWidth: 1000
contentHeight: 1000
Text {
text: flickable.visibleArea.xPosition
}
}
Change-Id: I615f9f9dc84903fb3a902f416a55e3ce3fece64c
Fixes: QTBUG-81098
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|/
|
|
|
|
|
| |
Amends 744e77b841878fb017c0f2d60607090008f28180.
Change-Id: I16e37aaf503eb62f67fca0e48be4c92c4a72ae46
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just do the typical
do {
[..stuff..]
} while(0)
in the macros
Fix the places that didn't have semicolons.
This should eliminate some compiler warnings complaining about
excessive semicolons
Change-Id: I6b0e7a55badfd0f80c3cd0e9e1da42dc41945485
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-76491
Change-Id: I69b0c4ec7c03f9421b18828516e064eff2b45518
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The root cause was that the QAbstractAnimationJob::finished() might delegate its
destruction to change.listener->animationFinished(this), and the original author
was aware of that and provided a RETURN_IF_DELETE macro to return early if itself
got deleted. In the bug's case, change.listener->animationFinished(this)
dispatched to QQuickItemViewPrivate::animationFinished() which called
QQuickItemViewPrivate::release() and deleted the QAbstractAnimationJob object
itself in the end.
However, any objects derived from QAbstractAnimationJob, or holding a pointer
to a QAbstractAnimationJob, may potentially fall into the code path calling
QAbstractAnimationJob::finished(). Any QAnimationJobChangeListener that directly
or indirectly deletes QAbstractAnimationJob should be very suspicious to this
kind of "heap-use-after-free" bug. Should ensure that the QAbstractAnimationJob
won't be referenced after deletion.
In the bug's case, within the code path triggered by ListView displacement
animation, the other affected classes by QAbstractAnimationJob are:
QQuickItemViewFxItem, QQuickItemViewTransitionableItem, QQuickTransitionManager.
To fix this, a new SelfDeletable class is factored out to simplify the self-deletion
test logic. Any affected classes are made to have a public member m_selfDeletable.
Any code paths that finally reach QAbstractAnimationJob::finished() are
wrapped with related util macro.
Change-Id: Idd33fc3f2d529fd7d8bb088c329101b1e70dd6c0
Task-number: QTBUG-44308
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
| |
QQuickFlickable::setContentX/setContentY used !=/== to compare qreal, which would
trigger binding loop warnings while using bi-directional property bindings.
Fixes: QTBUG-74128
Change-Id: I224a924e11c93cf047478ba0e09e10e57eedabde
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickItemPrivate::data_append() was not invoked when any kind of
Pointer Handler was directly declared in a Flickable (or subclass)
because QQuickFlickable redefines the default property to be its own
flickableData property. So we need to repeat the special handling
in QQuickFlickablePrivate::data_append() too. The handler must
be added to the private->extra->pointerHandlers vector, so that
QQuickItemPrivate::handlePointerEvent() will attempt to deliver
events to those handlers.
TapHandler seems OK (especially with its default gesturePolicy
so that it does not do an exclusive grab).
PointHandler seems OK.
DragHandler competes with Flickable for the exclusive grab.
pressDelay can help; or set acceptedDevices: PointerDevice.Mouse
to allow the mouse to drag but not flick, and the touchscreen
to flick but not drag.
Fixes: QTBUG-71918
Fixes: QTBUG-73035
Change-Id: Icb97ed5230abe0cb6ec0230b5b5759a0528df7e8
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
The internal flick functions were not written to handle empty flicks
in invalid directions. Guard our calls accordingly.
Change-Id: I34801a7e548160ce4895dd8a2f6c0b17172cd02e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we can tell when macOS is sending wheel events that represent
simulated momentum, and Qt::ScrollEnd is guaranteed to mean that
scrolling actually ended. So the timer to check whether it really
ended is no longer necessary.
This reverts commit 87a4d4babe0a3d6b8a57048205eccc7105931474.
Task-number: QTBUG-63026
Task-number: QTBUG-65160
Change-Id: I0988e934b43989a3501b89d0a77eee616328ece2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
| |
which was added in qtbase e09f5b17.
Change-Id: Id16ba131ac8a92beccaecb52a1e73627557a4939
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flickable.at[X/Y][Beginning/End] were being always notified of changes
at bulk. This is can be harmful in performance of QML applications that
will trigger change requests on the program whenever a property is
modified.
This introduces separate signals so it's not a problem anymore.
Change-Id: I729852df665ec34f532812dd0a45507d053d624c
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a Flickable contains an Item with a HoverHandler and a DragHandler,
and you drag it and release it, then during the next mouse move events,
since Flickable is able to filter those while they are being sent to
the HoverHandler, it would grab the mouse. Suddenly you'd be flicking
even with no mouse buttons pressed. I think I've seen similar behavior
in other scenarios too, at some point.
Change-Id: If79c8af2b62dc69f085513e0b7c8bf9b4d504572
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/quick/items/qquickloader.cpp
tests/auto/quick/qquickanimations/tst_qquickanimations.cpp
Change-Id: I0cb9f637d24ccd0ecfb50c455cc210119f744b02
|
| |
| |
| |
| |
| |
| |
| | |
This makes it easier to visualize how the properties work.
Change-Id: I04cb1a99a1f831e5c892cb27e4a0cd127fe450e0
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When it is set true, Flickable begins dragging by making the content
jump to the position where it would have been if there was no drag
threshold: that is, the content moves exactly in sync with the mouse
cursor or finger (as long as it's not hitting the bounds).
[ChangeLog][QtQuick][Flickable] Added a synchronousDrag property that
makes the content jump to the position it would have had if there was
no drag threshold, as soon as dragging begins.
Task-number: QTBUG-62902
Change-Id: I5f3b530956363172167896b0f19aec4a41bf82b3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-68933
Change-Id: Ibb5aa227e82825085e7214e17dcffcb17fd44157
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to d868bb4f3e4b0424fd4a2989ff1c82692b0f014c this
removes the check for scrollingPhase in movementEnding.
If movementEnding is invoked by some codepath other than timerEvent
(e.g. setContentY) and scrollingPhase is true this will again prevent
any further invocation of movementStarting from within the drag method
(see d868bb4).
As this check was introduced together with the movementEnding timer
(QTBUG-63026) and scrollingPhase is now checked inside the timerEvent
there should be no need for the check in movementEnding.
Task-number: QTBUG-67460
Change-Id: I88ad6e3ee56b88a66bb61798b8876324f4842f1e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On macOS a special movementEnding timer was added to the wheelEvent
handling to fix QTBUG-63026.
This has introduced a regression with wrong vData/hData.moving flags:
When the timer fires before the Qt::ScrollEnd phase is reached,
movementEnding is invoked early (can be reproduced with very slow scrolling
using the Magic Mouse). In this case movementEnding sets
vData.moving = false but not vMoved = false because scrollingPhase is
still true.
This will prevent any further invocation of movementStarting from inside
the drag method (it expects a change in vMoved) so once this situation
has occurred the "moving" flags will be out of sync.
Visible effect: If a ListView has a currentItem set with
setCurrentIndex, its viewportMoved method will no longer correctly set
the moveReason to "Mouse" because the check depends on "moving" flag as
an indicator for mouse interaction. This results in the view permanently
jumping back to the current item on any scroll operation because the
moveReason will be stuck at "SetIndex".
The fix is to ignore the timer event if scrollingPhase is still true.
Task-number: QTBUG-67460
Change-Id: I7cf02b8c625b7baf249ad26c4e0c3df874a18eae
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/plugins/qmltooling/qmldbg_profiler/qqmlprofilerservice.cpp
src/qml/compiler/qqmlirbuilder.cpp
src/qml/compiler/qqmlirbuilder_p.h
src/qml/compiler/qqmltypecompiler.cpp
src/qml/compiler/qv4codegen.cpp
src/qml/compiler/qv4codegen_p.h
src/qml/compiler/qv4compileddata_p.h
src/qml/compiler/qv4compiler.cpp
src/qml/compiler/qv4compilercontext_p.h
src/qml/compiler/qv4isel_moth.cpp
src/qml/compiler/qv4jsir.cpp
src/qml/compiler/qv4jsir_p.h
src/qml/jit/qv4isel_masm.cpp
src/qml/jsruntime/qv4engine.cpp
src/qml/jsruntime/qv4functionobject.cpp
src/qml/jsruntime/qv4runtimecodegen.cpp
src/qml/jsruntime/qv4script.cpp
src/qml/jsruntime/qv4script_p.h
src/qml/qml/qqmltypeloader.cpp
src/quick/items/qquickanimatedimage.cpp
src/quick/items/qquickanimatedimage_p_p.h
src/quick/scenegraph/compressedtexture/qsgpkmhandler.cpp
tests/auto/qml/qmlplugindump/qmlplugindump.pro
tests/auto/qml/qmlplugindump/tst_qmlplugindump.cpp
tools/qmlcachegen/qmlcachegen.cpp
tools/qmljs/qmljs.cpp
Done-with: Shawn Rutledge <shawn.rutledge@qt.io>
Done-with: Lars Knoll <lars.knoll@qt.io>
Done-with: Ulf Hermann <ulf.hermann@qt.io>
Change-Id: I010e6525440a85f3b9a10bb9083f8e4352751b1d
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
.qmake.conf
src/qml/compiler/qv4codegen.cpp
src/qml/compiler/qv4compileddata_p.h
src/qml/debugger/qqmlprofiler_p.h
src/qml/jsruntime/qv4engine.cpp
src/qml/memory/qv4mm.cpp
src/qml/qml/qqmlcomponent.cpp
src/qml/qml/qqmlobjectcreator.cpp
src/qml/qml/qqmlobjectcreator_p.h
src/qml/types/qqmldelegatemodel.cpp
src/quick/items/qquickitem_p.h
src/quick/items/qquickwindow.cpp
tests/auto/quick/touchmouse/BLACKLIST
tests/benchmarks/qml/holistic/tst_holistic.cpp
Change-Id: I520f349ab4b048dd337d9647113564fc257865c2
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Followup to ef8c6f6a0bf5e4c9ee41306f2df59048ab96038f: we emit
movementEnding for the benefit of the user, scrollbars, decorators
etc. in case the ScrollEnd phase means that movement really ended
(it means the user lifted his fingers from the trackpad,
but momentum events can cause the movement to continue after that).
But in case movement didn't end, we don't want to have a jump when
it resumes. But scrollingPhase will be true after an event with
ScrollBegin phase, and false after an event with ScrollEnd,
also false if the mouse is an ordinary wheel mouse without phases.
So when the timer fires, if the user has not yet lifted his fingers,
scrollingPhase is true, and that means scrolling isn't really ending,
so we should not set vMoved to false.
Setting vMoved to false will cause the drag() function to
reset vData.dragStartOffset to the current dy value, which
ultimately causes the jump in contentY. It should be done only
when scrolling really ends. If the timer fires and scrollingPhase
is false, we can be sure it really ended. But if you flick, then
rest your fingers, then lift them, there is no momentum, so the
final event has scroll phase ScrollEnd, and we need to run the
timer one more time to detect that there are no more updates
and finish the transition back to the default state (set vMoved back
to false, emit signals such as movementEnded, etc.)
The ultimate solution is to add another Qt::ScrollPhase enum,
such as ScrollMomentum, but we should not do that in the 5.9 series.
Task-number: QTBUG-63026
Change-Id: I854c52a680028cb1d43b133be65653d87a05a0b1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
tests/auto/quick/pointerhandlers/flickableinterop/data/FlashAnimation.qml
tests/auto/quick/pointerhandlers/flickableinterop/data/Slider.qml
tests/auto/quick/pointerhandlers/flickableinterop/data/TapHandlerButton.qml
tests/auto/quick/pointerhandlers/flickableinterop/data/flickableWithHandlers.qml
tests/auto/quick/pointerhandlers/multipointtoucharea_interop/data/pinchDragMPTA.qml
tests/auto/quick/pointerhandlers/qquickdraghandler/data/DragAnywhereSlider.qml
tests/auto/quick/pointerhandlers/qquickdraghandler/data/FlashAnimation.qml
tests/auto/quick/pointerhandlers/qquickdraghandler/data/Slider.qml
tests/auto/quick/pointerhandlers/qquickdraghandler/data/draggables.qml
tests/auto/quick/pointerhandlers/qquickdraghandler/data/multipleSliders.qml
tests/auto/quick/pointerhandlers/qquicktaphandler/data/Button.qml
tests/auto/quick/pointerhandlers/qquicktaphandler/data/FlashAnimation.qml
tests/auto/quick/pointerhandlers/qquicktaphandler/data/buttons.qml
tests/manual/pointer/content/FakeFlickable.qml
tests/manual/pointer/content/FlashAnimation.qml
tests/manual/pointer/content/MomentumAnimation.qml
tests/manual/pointer/content/MouseAreaButton.qml
tests/manual/pointer/content/MouseAreaSlider.qml
tests/manual/pointer/content/MptaButton.qml
tests/manual/pointer/content/MultiButton.qml
tests/manual/pointer/content/ScrollBar.qml
tests/manual/pointer/content/Slider.qml
tests/manual/pointer/content/TapHandlerButton.qml
tests/manual/pointer/fakeFlickable.qml
tests/manual/pointer/flickableWithHandlers.qml
tests/manual/pointer/flingAnimation.qml
tests/manual/pointer/joystick.qml
tests/manual/pointer/main.cpp
tests/manual/pointer/main.qml
tests/manual/pointer/map.qml
tests/manual/pointer/map2.qml
tests/manual/pointer/mixer.qml
tests/manual/pointer/multibuttons.qml
tests/manual/pointer/photosurface.qml
tests/manual/pointer/pinchDragFlingMPTA.qml
tests/manual/pointer/pinchHandler.qml
tests/manual/pointer/singlePointHandlerProperties.qml
tests/manual/pointer/tapHandler.qml
tests/manual/pointer/tapWithModifiers.qml
tests/manual/shapestest/main.cpp
Change-Id: I4f233a521305fab1ebfecbac801da192434ed524
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/quick/items/qquickwindow.cpp
src/quick/items/qquickwindow_p.h
tests/auto/quick/quick.pro
Change-Id: Ia12f20e95fb151bbbc75dbf187364a924cd0bc7a
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's such a common mistake to observe that they normally go to zero at
the top-left corner, but fail to realize that they won't always do that.
Task-number: QTBUG-64219
Task-number: QTBUG-22894
Task-number: QTBUG-27884
Change-Id: I6bc81d4761debdaff8fb3366bf1e944241207157
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
| |\|
| | |
| | |
| | | |
Change-Id: I8ede7e36592cd21f3e4a0a9b30dbe26bb40fe69b
|