| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to un-blacklist the test for QTBUG-60123. To that end:
revert 7b2e2117162594a2d0234bb02408f5b5a446488b and its followup
6933b7e8e6dc279a8eb34e1f4c60bc109dfb7d26. There is no detailed bug
report explaining exactly why those were done, just the comment on code
review: "This fixes the desktop components' combo box on linux
re-opening at random times", probably referring to a combobox popup
window in Controls 1. But when using QWidget::createWindowContainer()
in two different windows and clicking MouseAreas in each of them, it
turns out that this change of focus is causing the mouse grab to be
canceled. The grab should be naturally given up after mouse release;
canceling prematurely doesn't make sense.
The Qt 5 fix for this bug was e0c30279ec1fad88346ed3fb483bc3c672fdd01b
which tracked the grab on a per-window basis. It would be difficult to
do that again now (change QPointingDevicePrivate::setExclusiveGrabber()
to store a separate grabber for each window in which a grab occurred?
what could go wrong...) It seems odd to have the same QEventPoint
grabbed in two different windows at the same time, but popups need event
forwarding so maybe that was why (if a MouseArea triggers the popup,
should it stay pressed and keep its grab? the subsequent mouse moves and
the release need to be forwarded to the popup, so maybe something inside
the popup needs a grab, simultaneously or not). Anyway we don't have
actual popup windows in Controls 2 right now; and we know that event
forwarding for popups needs work in QtGui so that it will be easier when
we try again to have them in Qt Quick (QTBUG-68080). So perhaps the
original workaround has outlived its usefulness: popup event forwarding
needs to be handled at the lower layer, not in Qt Quick.
Task-number: QTBUG-57253
Task-number: QTBUG-60123
Task-number: QTBUG-86729
Change-Id: I56dbc3bb94f66a7f26f79a97bcb2f2bbc0b7aa92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In QQuickWindow, we instantiate QQuickPaletteProviderPrivateBase, which
in turn instantiates its updateChildrenPalettes method, which then calls
QQuickItemPrivate::inheritPalette. However, QQIP is an incomplete type
at this point. Including qquickitemprivate_p.h would currently create a
cyclic dependency, and breaking that dependency might mean outlining
performance sensitive code.
Thus we instead (ab)use the fact that updateChildrenPalettes is virtual,
do nothing in the specialization for QQuickWindow and instead implement
the method in the same way as an override in QQuickWindowPrivate.
Task-number: QTBUG-88457
Change-Id: I49b357d7a67f1945a4d3c25e8cabd428d1454aa7
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>
|
|
|
|
|
|
|
|
|
|
| |
QEvent is a polymorph type, and even though it has a copy constructor,
we shouldn't use it.
Use the pattern as in QQuickMouse/WheelEvent.
Change-Id: I26ab7b831e1e8dd156c32417f74bc7d800bcf71c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: Iacfffdc774d5ea6980af7a29da07a82f17799e33
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the qt.quick.hover.trace category, the position is the most
important thing for now. The output for "q" is verbose and usually
there's only one window anyway, so just put the title last, in case
we need to debug a multi-window scenario.
Dealing with hover in multi-device scenarios is going to be interesting
one of these days.
Change-Id: I2b687085432ce2e02ca764b8b4669282e0180c54
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
| |
Pick-to: 5.15
Change-Id: If63f4c59f18bc0754ce2e68e424f6efd0f512d30
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WheelHandler was only reacting to one wheel event between mouse moves,
because it got added to the QQPointerHandlerPriv::deviceDeliveryTargets()
vector, and was not removed at the beginning of delivery of subsequent
events, as QQuickWindowPrivate::deliverPointerEvent() does. (In Qt 5
the equivalent vector was cleared in QQuickPointerMouseEvent::reset().)
Wheel events are delivered via deliverSinglePointEventUntilAccepted()
(grabbing the wheel is still not implemented). Native gesture events
are delivered that way too; and sure enough, the same bug happens on the
macOS trackpad, whether you are attempting to do pinch zoom or just
two-finger-flick.
tst_QQuickWheelHandler::nestedHandler() sends multiple wheel events
in a row, so we do have some test coverage, and hopefully this issue
explains why it needed to be blacklisted.
Fixes: QTBUG-88428
Task-number: QTBUG-86729
Change-Id: Id1ed4a38dfa3eb2253c4a60f09f80aea0f69707e
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>
|
|
|
|
|
| |
Change-Id: I78fe89cd97b462299969d57cda099ce54fa8078a
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added check into deliverMatchingPointsToItem method for Android device.
In QT_VERSION below 6.0.0 touchEnabled for QtQuickItems is set by default to true
It causes delivering touch events to Items which are not interested
In some cases it may cause a crash. For example using Material Style in Android.
QQuickShaderEffectSource may be deleted and then try to handle touch
Fixes: QTBUG-85379
Pick-to: 5.15
Change-Id: Ia2c4e016db57ef9c86fcc31d4cfba6154068a546
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: I32f34979a45fea6ee1dfc163fa85f340eb7ca1e3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
| |
Amends 23dbe3d6e0d3338812ad9f614028a6fdc5a54090. A similar change
was done to QSGRendererInterface. Therefore the QML API should
follow suit.
Change-Id: I2f6d1aeefc17bf3b58b7683f46511d4433194e1c
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This is due to not fixing the graphicsApi() check: OpenGL and OpenGLRhi
are now the same. The condition should have been removed anyway since it
makes no sense in Qt 6.
Fixes: QTBUG-88208
Change-Id: I60db54121a0a74bfa3ca1650f90244f36fc7010f
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
| |
::OpenGL and ::OpenGLRhi are the same thing now.
Change-Id: Ic905eb868a7a62d32261bdc025b20e182ed6db7c
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
| |
Change-Id: Iae4a82af31bbefbe34ceef7e68c411e67b41dcd8
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove links to modules and examples that are not part of Qt 6.
- Remove links to entities marked as \internal
- Add missing enum value and QML property docs where it's trivial
to do so.
Task-number: QTBUG-88156
Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
|
|
| |
QEventPoint knows nothing about Qt Quick.
Amends a97759a336c597327cb82eebc9f45c793aec32c9.
Change-Id: Ie672e0431d3280abff7c34315a2c00cb02697a61
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
qdoc would interpret the two {} expressions as just one link
Change-Id: I06c5f6ebed097ffc7e93c2ebe94045a8f6a58d78
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
|
|
| |
All QFontDatabase APIs are static, use them accordingly.
Task-number: QTBUG-88114
Change-Id: Iaa6be07e47adcdb5115e475cc5228f403e9a2b27
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
Amends a97759a336c597327cb82eebc9f45c793aec32c9
Change-Id: I43f03b699fe2b5e43c0bfe3e1ece3ce7c965f886
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
Since we depend on C++17 now, all of these can go.
Change-Id: I0484fd4bb99e4367ec211c29146c316453729959
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
| |
Also replace Q_DECL_NOTHROW with noexcept.
Task-number: QTBUG-87973
Change-Id: I1471d65076ece5ab6d5efdf0e50b02751789d32b
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Worrying about the window's touchmouse is really not a relevant concern
for a touch-only item; and grabs are done by grabbing the specific
points that the pincharea chooses to handle, not by grabbing the
touchmouse. We simply didn't have suitable API in Qt 5.
Also some drive-by fixes: better packing and initialization in
QQuickPinchAreaPrivate; and the stealMouse variable has only
been set, not checked, for a long time, so we can remove it.
Remove unimplemented handlePress() and handleRelease().
Change-Id: Ia76dc9b9974f663b13c4bb9dac32efe8ed7815c5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c5085eb8905f1a3c070f866746110980e84be271.
It can cause crashes and only fixes an edge case that can't
be encountered during normal usage.
Pick-to: 5.15 5.15.2 5.12
Change-Id: Ia265f0d6716b59a0f483e5a114b3f3b1a76fe898
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: Ie3c996b6e0635bb28b0c9686a4d9207837906e1f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I4cf59a1afacd56be114393e70f132d25a8f084eb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Stationary points are delivered like updated points after
05dc0a387ae324f2d6f3d7e633a0a49473f6957a
- QQuickItemPrivate::localizedTouchEvent() seems to need to
detach QEventPoint instances with Released state, to avoid
losing the localization during delivery
- calling stationary() or release() without position causes
the event to occur at the middle of the item, not at the
last-known position as the test was expecting
Task-number: QTBUG-86729
Change-Id: I6bdcebc04a11d93d1d006f8269c1df2e9206a393
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In tst_qquickitem::ignoreButtonPressNotInAcceptedMouseButtons(), when
the right mouse button release occurs, the item has a grab, but it's
not interested in the right button, only the left. But of course
we still want to deliver mouse drags, so if the button is NoButton
and the item is the grabber, it gets the event.
Task-number: QTBUG-31861
Task-number: QTBUG-86729
Change-Id: I952acc721a5f80a7fc5619c5fea640dae805e9c8
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When event handling code explicitly calls QPointerEvent->setAccepted(),
all points get accepted, because that function is virtual now and makes
it so. But the event is pre-accepted before delivery, because by
tradition, the item must ignore the event if it doesn't handle it, but
is not required to accept if it does handle it. Then in
deliverPressOrReleaseEvent() (and other places) we check
allPointsAccepted(), in case the event is a touch event and some item
chooses to handle only a subset of the points. So it was not OK to
remove this line that keeps them in sync after tradtional mouse
delivery, which was added in 47ee54455beb1a063515041f85b4c216132491b3.
The result was that delivery "kept going" past items that would neither
accept() nor ignore() the mouse event, such that items further down
could steal the grab, etc. In this case it was the ComboBox itself
that received the press event, stole the grab from the TextField,
and so the TextField did not get the mouse move and release that
would select a range of text.
Amends e783ef04fbbaa9a53121a6f575414b48043a10d2.
Fixes: QTBUG-87947
Change-Id: Ib856d58a59c798c7bbfc5a222e2462a839fc2bdd
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
| |
-should be "look and feel"
Task-number: QTBUG-88010
Change-Id: I5eef099eec362144651dd95d74023a571c4ac08c
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it stood we would never updated the paint node upon
changes to padding. The result was that if you changed
padding after start-up, you would not see any visual changes.
This patch will ensure that we update the paint node
when we change padding.
Pick-to: 5.15
Change-Id: I2e9ed4406e8f01c26d1fa2ef09fe35a50f28411c
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I47a0a4aad7cff956b2ebd450870d625f817690d4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Traditionally, a QQuickItem subclass could override touchEvent();
if the event is still accepted when it returns, that meant the item
handled all the points, so completely that the item should get an
implicit grab of those points, and they should not be delivered further
to any other items underneath. But it's often not so simple in
multi-touch UIs, which is why each QEventPoint has its own accept flag.
QPointerEvent::setAccepted() now iterates the points and calls
QEventPoint::setAccepted() on each; so QQuickWindow doesn't need to do
anything to make that happen anymore.
Change-Id: Idbe7abf278411ee2fea598c1a1939f4bdb214aa0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
view child
When two table views are connect through the syncView property, both
views will flick when you flick on either of them. This also means
that if you fast-flick more than a page on the sync view child, the
sync view needs to rebuild, like if you did the fast-flick directly
on the sync view. Because we updated the sync view's viewportRect too
soon while fast-flicking on the the sync child, we didn't detect that
it was a fast-flick, and that a rebuild was needed. The result is
that you could sometimes end up with the views getting out-of-sync.
This patch will allow TableView to only move the viewport without
updating the internal viewportRect while flicking. The viewportRect
will instead be sync-ed at a later point, like we do when you flick
on the sync view directly. This will ensure that we rebuild if
needed, also while fast-flicking on the child view.
Task-number: QTBUG-87821
Pick-to: 5.15
Change-Id: Ifc74473eb43406acaa8e24880066fb4ca89d3a4e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For tables of non-trivial sizes, we usually don't know what the
content size will be unless we load all rows and columns, which
we simply cannot do. Because of this, we have up till now chosen
a strategy where we normally just calculate a predicted content
size up-front, when we table is built, and afterwards just stick
to that prediction.
This strategy works for big tables that fills more than one size
of the viewport, and if the number of rows and column in the model
stays around the same. But for tables that start off smaller than
the viewport, and later expands to grow out of it, it simply fails.
And the failure is such that the tableview can get stuck, with no
way way for the user to flick around to see the rest of the contents.
An example is TreeView that might only show the root node at
start-up, but as you start to expand the tree, it will quickly add
more rows than what fits inside the viewport. And in that case, the
contentHeight will be totally off, and in turn, make the scrollbar
be based on wrong values, and sometimes not work at all (e.g if
it has the flag Flickable::StopAtBounds).
This patch will change the implementation so that we recalculate
the content size whenever it should logially change. That is, if
e.g the model add or remove rows and columns, or if you change
spacing. This still doesn't mean that contentWidth/Height reports
the correct size of the table, but at least it will be a better
guestimate for smaller tables, and at the same time, work
together with Flickable and ScrollBars.
Pick-to: 5.15
Fixes: QTBUG-87680
Change-Id: Ie2d2e7c1f1519dc7a5d5269a6d25e34cf441b3fe
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we cannot be sure when the event loop that would usually
handle deferred deletions will run the next time we have to delete these
components immediately otherwise we might run out of memory.
Fixes: QTBUG-86676
Pick-to: 5.15 5.12
Done-with: Maximilian Goldstein <max.goldstein@qt.io>
Change-Id: I01d74f7eea442f8ba240dd66a4cedd6316fbeec2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change in qtbase which made removeAll had the unfortunate side
effect that were deducing type int now (instead of converting 0 to the
null pointer constant), which -after a few indirections- leads to
3365: src/quick/items/qquickwindow.cpp:3785:22: required from here
/usr/include/c++/10/bits/predefined_ops.h:268:17: error: ↩
ISO C++ forbids comparison between pointer and integer [-fpermissive]
268 | { return *__it == _M_value; }
| ~~~~~~^~~~~~~~~~~
Change-Id: I2ba7c561a2431a8a71f77068daef60d5ae62f17c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Pick-to: 5.15 5.12
Change-Id: I85e60dd5c8643a8e443a14250987b2b38c78dc08
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible for itemChange to be called during destruction when
deleting the QQuickShaderEffectImpl. We nullify m_impl before deleting
it via another pointer to it, so we must check that it's not null
before trying to use it.
Pick-to: 5.15
Fixes: QTBUG-86402
Change-Id: If4955445f7cc0d1f376bc9b86b95e1cca4d88ede
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
| |
From API review.
Change-Id: Icc4f571603fe8d59851f768fec408070989623c3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
| |
Change-Id: I1f2171e18ec3df71f7eaec1be0e0e0d1442a3860
Reviewed-by: Laszlo Agocs <laszlo.agocs@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use an if-test to check if the document width has changed before
we set the new value. The problem is that the value we test
against is different than the value we set. The result is that
we can sometimes skip setting a new width on the document, even
if padding has changed.
This patch ensures that we use the same width for both testing
and setting.
Pick-to: 5.15
Change-Id: Ia8391999e8cc2b5be72fe525d396bf8c17ba0fa2
Reviewed-by: Mitch Curtis <mitch.curtis@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QEventPoint is explicitly shared, so a QMouseEvent synthesized from
a QTouchEvent shared the same QEventPoint instance.
When QQuickFlickable::filterMouseEvent() calls cloneMouseEvent(),
it was re-localizing the point for the flickable, after it had
already been localized for delivery to the original receiver item.
This caused a lot of failures in Controls, e.g. for any button inside
a Flickable, QQuickAbstractButtonPrivate::handlePress() would be given
the wrong position.
After filtering, we need to be able to resume delivery to the
original receiver item without re-localizing the point.
During filtering, the filtering parent should receive the same version
of the touch event that contains only the points that would be sent
to the receiver item, not the potentially more-complete original event.
Fixes: QTBUG-87157
Change-Id: I7eec6f5ecfe9f042199f0944897c04fbffb2172e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|