| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Change-Id: Ic3a11d24fdc02fa383350997083b38407d75feab
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit ef16f8876d70c9fab4780f5063dc463e38ba3056)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the ability to focus an item by clicking (such as a TextInput)
when it's part of a subscene mapped to a 3D object in Qt Quick 3D,
even if there are multiple subscenes with focusable items.
QQuickDeliveryAgentPrivate::setFocusInScope(subsceneRoot, textInput)
for example did not succeed; for one thing, this check fails:
// Does this change the active focus?
if (item == rootItem || scopePrivate->activeFocus) {
because in a 3D scene, so far the viewport has focus by default,
so the given scope (subscene root) does not have active focus.
Each window ultimately has one actively focused item, so we need to
delegate to the delivery agent belonging to the window's root item, to
set its active focus. It's not even clear whether it's really a good
idea for each subscene delivery agent to have its own
QQuickDeliveryAgentPrivate::activeFocusItem. It might give us
flexibility: perhaps each subscene root item should be a focus scope,
and each delivery agent should decide which item would be hypothetically
focused if the whole subscene got focus. But for now, it seems enough
to set the activeFocusItem on the root item of the whole scene.
Another problem was that when QQuickItem::forceActiveFocus() goes up the
parent hierarchy, it didn't find a focus scope. So when you clicked on
a TextInput that already had its focus property set to true,
1) QQuickItem::setFocus() does nothing because d->focus is already set
2) QQuickItem::forceActiveFocus() did not find a parent focus scope
Therefore neither of them changed anything, and it wouldn't get active
focus. Setting the ItemIsFocusScope flag on each subscene root item
fixes (2), and that seems to be enough for now.
Another problem was that QQuickWindow::event() was calling
QQuickDeliveryAgent::grabberAgent() even when delivering an event that
is NOT a press event, in spite of the comment "When delivering _update_
and _release_ events to existing grabbers, use the subscene delivery
agent, if any." A hover event often results in a HoverHandler getting
a passive grab, but that passive grab is not a reason to deliver a
subsequent press event to the same subscene. When the mouse moves,
we need to start over with picking in the 3D scene. When the 60fps
frame-synchronous hover event occurs, we need to start over with
picking, in case 3D objects are being animated under the cursor.
When a press occurs, we need to start over with picking in case the
press occurs in a different location from the last hover (even though
that's unlikely with a mouse, it happens easily with a touchscreen).
Another problem was that QQuickItemPrivate::deliveryAgent() was not
finding the subscene DA during delivery of key events. A child item's
extra is often not allocated, but we still need to keep looking at the parents.
The optimization from 68c103225f4e8bd6c1b18ef547108fd60f398c0f was also
wrong: after an Item's default initialization, we always need to do the
search for the subcene DA. Only if we are sure that the item is NOT in
a subscene (as in all normal 2D scenes) we can avoid doing that search
next time.
Consolidate the number of lines of output in the qt.quick.focus logging
category and show the activeFocusItem transition. As with most logging
in Qt Quick, it's expected that you set QT_MESSAGE_PATTERN to include
%{function} so that you can always see where each line comes from.
Therefore the log output itself has only minimal context (as in
"q focus item x in scope y") rather than repeating the function name.
Change-Id: I1b2a989c02c58c966653f965c0de512aa641bb99
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 543598a6cc07d67e7651c9f65c058465ea6d8425)
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Fixes: QTBUG-91497
Change-Id: Ia280e768537404505481ea7046922785531e77c2
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit e83e91bad4bc85a925eab50e2f58fc3a7ae21112)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, we can get a crash in QQuickPopupItemPrivate, which does not
have a palette when using the Fusion style (so m_palette is nullptr),
but instead hands us its popup's palette.
Change-Id: Ib472139735dc3a7892771c6097267c0ec6902a99
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6b8a6b9fc86e94c1160d640a2b9718a7ae275b08)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
| |
Change-Id: Ia1ca8276560f913e84b9e4c119cd1ced89737790
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 1a738838c4a199c61fce32c7eaba466181526335)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so
for every window there's an object responsible for event delivery,
while the window itself is mainly responsible for rendering (separation
of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now
be used in cases where the scene doesn't directly belong to a window,
such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D
scene. In that case, we must remember which delivery agent was in use
at the time when a QEventPoint is grabbed and deliver subsequent updates
via the same DA. There's also a QQuickDeliveryAgent::Transform
abstraction which subscene-management code (such as QQuick3DViewport)
can implement, to provide a formula to map the window's scene
coordinates to subscene coordinates; if defined, it will be used
during delivery of subsequent updates to existing grabbers.
Task-number: QTBUG-84870
Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 68c103225f4e8bd6c1b18ef547108fd60f398c0f)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Event delivery logic will live in util/qquickdeliveryagent.cpp now.
The actual QQuickDeliveryAgent class will be created in a followup patch.
This patch is roughly the same as this series in dev branch:
44eebdf5f5fe3bd7be16bc0ef05f8fc63e38a9f2
ca9c29348a9e149109d9d381cdd44538160b7898
902c68f3ceaae407306ca5a3fdcdcfa159009e78
79f0af6cd097f55eacb763574e173f134c9c0a32
0ccea574f8e4e9a3954ef3bb95909565957bacbe
dbdee417dc073a0da3c99849a3f393fa3cb660e9
Change-Id: I25f234d0550768cb01cd80c38525291202b25d99
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If validation did not pass after text pre-editing is finished, it need
to be roll back to state before pre-editing started.
Before this change, if validation did not pass, text was always rolled
back to previous state. In pre-editing text case, it means back to the
state in which part of the text was removed (and later changed to
pre-edited text). It may cause a situation of removing part of the text
that was already validated
Fixes: QTBUG-90239
Change-Id: I3ec39e0f6b8a93d4e6fd190af30d4c80a0e495eb
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit b1ae151acc80254ab0ec2937c55b99223205875c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We prefer camelCase rather than SHOUTING for module constants.
It fits well to have logging categories as constants that start with lc.
That has become conventional in various modules, and we've been using
that convention already for some time when defining new logging categories.
Now we finish renaming the Qt Quick ones, ahead of a refactoring which
will result in moving some of them around.
Change-Id: I47003b9e525fe70d35dbd2450d03379b52d67c1d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit a8685fdb4d57c0ba36d80c395c2ae878595f04da)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not set m_cursor (cursor position) before calling
removeSelectedText() in processInputMethodEvent(QInputMethodEvent *)
method.
Before this change, DeleteSelection command was added to history with
new cursor position. If this command will be later rolled back, cursor
position will not be set correctly. It should be set to position
before handling the event.
Task-number: QTBUG-90239
Change-Id: Ib5e46d232e6b32f904e745da4f9e5bc03a58963f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 6ec8c62ca22c363fa00e085de10198a90e3d65dc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickItem returns whether it contains QGuiApplicationPrivate's
lastCursorPosition. Since that position stores the coordinate last seen
by Qt (the window border), it will always be within the window, and
within an item that covers that part of the window's border.
However, QQuickWindow stores the lastMousePosition as well, and resets
that value when it receives a QEvent::Leave. We can use that to test
whether the window that contains the item has seen a Leave event, in
which case the item is definitely not under the mouse.
Notes on the test: That we use QPointF() as the "reset" value leave the
small possibility that the cursor might be at position 0,0 of the window
(ie inside the window), and the QQuickItem there will not be under the
mouse. We can't confirm this (through an expected failure test), as
QTest::mouseMove interprets a QPoint(0, 0) as "center of the window".
And since we can't simulate mouse moves outside a window's boundary
using QTest::mouseMove, the test needs to explicitly synthesize a
QEvent::Leave for the window.
Fixes: QTBUG-87197
Change-Id: I04870d6e914092275d9d790312fc702fb99f2935
Done-with: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit ba1246c543118515ea244787f3d7f9c1133ccf0f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
| |
Injected signal handlers are bad practice because they aren't declared.
Task-number: QTBUG-89943
Change-Id: I3a691f68342a199bd63034637aa7ed438e3a037b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 4cc91a6a0e4f9063233a4d6554ae64855cf99c14)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no reason to hide the inputMethod explicitly when finishing
the editing. This will be taken care of for us by the platform plugin
and will account for a situation where Qt Quick Controls 2 will check
if the item had focus when it is in an popup being closed at this point
too.
Change-Id: I687718ae9b4fabbf6456597a475507d2ec1a1f45
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 6da66ff611902d8c4d485568d746f49c69f1330f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
It is not conforming to the include conventions (module missing)
and thus breaks the Qt for Python doc build.
Introduced by 48b4c1f450109b148f03f62574d78b460859c4a1.
Pick-to: 6.0
Change-Id: I1ff56a967c457f1909b7f6e2e430458e3a3f47c9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, when the QGuiApplication is shutting down while there
is an active QAnimationDriver and an incubating object, the
QQuickWindowIncubationController will try to access an already
destroyed QSGRenderLoop. So use a QPointer to guard the QSGRenderLoop
access.
Fixes: QTBUG-90489
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I528e06ff22dfcad804593db6771d9163b21808f4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QRhi has APIs (but private ones) that allow retrieving and
restoring the contents of the "pipeline cache". (which may map
directly to VkPipelineCache, or may be a simulated, OpenGL
program binary based solution)
In many cases it is convenient if the saving of the cache blob
to a file, and then, during subsequent runs of the application,
the loading of cache contents, can be enabled via environment
variables:
QSG_RHI_PIPELINE_CACHE_SAVE=filename maps to setting the
EnablePipelineCacheDataSave flag on the QRhi, and writing
the collected data to file upon application exit. (more correctly,
when the QRhi is about to be destroyed by the render loop)
QSG_RHI_PIPELINE_CACHE_LOAD=filename maps to attempting to read
the contents of the specified file, and, if successful, passing it
to QRhi right after initialization. When supported and the data is
not corrupt or incomplete, the result is likely improved pipeline
creation times (the exact details depend on the driver with Vulkan,
while with OpenGL it all maps to glProgramBinary instead of compiling
from source)
Setting QSG_INFO=1 can be useful to see what is happening when the above
2 env.vars. are set.
With OpenGL the simulated "pipeline cache" is orthogonal to the Qt 5 era
shader program disk cache: loading from both is supported transparently
to the application. When QSG_RHI_PIPELINE_CACHE_SAVE is enabled, the
disk cache will not be written to.
Task-number: QTBUG-90398
Change-Id: I82d9a81e9dab39d3513a6aa7c6e1ff748a4ec6e5
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
| |
As all QRhi stuff is private, it needs to have a public counterpart in
Qt Quick in order to fully support the case of Vulkan-based
QQuickRenderControl usage.
Change-Id: Iaf9a7aa56022acd31af6ebf16de6b83a04966ff4
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it stood, we wouldn't cancel touchMouseSynthesis after
receiving a touch cancel event. The result would be that
the first touch event sent to QQuickWindow thereafter would
have touchMouseId set to value different from -1. This
again would fool QQuickWindow into believing that the
event belonged to a touch event it has synthesized
before, and it would as such take a different/wrong path
for delivery.
This caused text selection to fail on iOS, since a
press-and-hold on a line edit from QPA would cancel
the touch event and show a magnifier glass. When the
user later touched inside the line edit again to
move the cursor, this new touch event would not be
delivered to the text edit.
Pick-to: 6.0
Fixes: QTBUG-90485
Change-Id: Iad640ae57317ea86ee68ca053654b0b30ade003a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes handling of hovered so that the property is still updated on
disabled items, so that other items can bind to it. This is in
particular useful for tooltips.
[ChangeLog][Behavior Changes] QQuickItem::hovered will now update even
when the item is disabled.
Fixes: QTBUG-30801
Pick-to: 6.0
Change-Id: Id17298f657d7631b0e5019138ba33a7d5f863475
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
Remove all qmake project files, except for examples which are used to
test that qmake continues to work.
Change-Id: Ic4abb72dc2dcd75df7a797c56056b6b3c5fe62ac
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing events as objects or references in signal parameters requires
copying, and we removed the broken copy semantics from QEvent for Qt 6
as much as possible.
QVariant::fromValue still allows creation of a QVariant from a type
that doesn't have a (public) copy constructor, which is why this
passing of a QWheelEvent through a QVariant to QML went unnoticed.
While QWheelEvent is a gadget and thus supposed to be invokable from
QML, it's still a QEvent. Most QEvents are not gadgets - like QKeyEvent,
QMouseEvent, QTouchEvent. We have QQuick*Event QObject wrappers instead
to provide access to the low level event data from QML.
So, use a single QQuickWheelEvent object instead to pass the data to
QML, that class is designed for exactly that prupose. We need to copy
the data anyway, and since we don't need to create/destroy the wrapper
object for each event, this has no practical overhead.
Extend the QQuickWheelEvent to provide access to the phase information
of QWheelEvent as well, and simplify the reset() method.
Note: making the QQuickWheelEvent store the QWheelEvent directly would
allow passing calls to setAccepted through to the QWheelEvent. That
is left for a future cleanup, and another reason for not passing events
around as copies.
Fixes: QTBUG-89594
Pick-to: 6.0
Change-Id: Id86a9b30c5a8c7c50091e464e368568a7f5ca2ea
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickText attempts to reduce relayouting. However, it was a bit to
aggressive in doing that. If only the width changed in a geometrychange,
it would not relayout if widthMaximum was true. However, if the width
goes from 0 to greater than 0, the value of widthMaximum should have
actually been false (but we would only notice this after relayouting).
Thus, don't skip relayouting in that case.
Amends 56ade46b4234bb828b8e4f9a6bf83b5687bd122e, which fixed the same
issue, but for height.
Fixes: QTBUG-83408
Fixes: QTBUG-33608
Pick-to: 6.0 5.15
Change-Id: I14b610c703eb0496c71de7b12ad9fcf16842af64
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
|
|
|
| |
Introduce a QSGOpenGLTexture::fromNativeExternalOES() function
which internally passes in the flag QRhiTexture::ExternalOES
when creating the wrapping QRhiTexture.
Change-Id: I919e2539304d3aeaa6bc8e5953d96adc810abb12
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only place where it was still used is QQmlOpenMetaObjecType. The
only effect of QQmlCleanup is that clear() is eventually called by the
engine. In the case of QQmlOpenMetaObjectType the only effect of that
was that the "engine" member was reset. However, the only place where
that member was used was in setCached(), and in that place it was
irrelevant. There is no reason why setCached() should be prohibited when
there is no engine. We may be worried that the property cache assigned
to the open metaobject might go away somehow if there is no engine, but
the cleanup mechanism clearly demonstrates that checking for the engine
on setCached() does not protect against this.
Fixes: QTBUG-90004
Change-Id: I05445eaeb53a64c70de366090ea2ee4aecf2bad8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
When removing items from groups actively shown by a model filter a warning
and assert was triggered in the past. This change fixes this behavior.
Fixes: QTBUG-86017
Change-Id: I49b7498a3d03141b654e453a3c35a43fc7ba804a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
| |
As opposed to being local to the item's parent.
Pick-to: 6.0 5.15
Change-Id: Idcf2cdbedcac24a6890ce761c3f2a23f2c7a8dc4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We quietly recommended calling setAcceptTouchEvents() in the Qt 5.10
release notes in any Item subclass that wants to receive touch events,
and in the docs for setAcceptTouchEvents() itself; but the message about
the impending behavior change might not have been obvious enough.
In Qt 6 it becomes mandatory, so clearer docs will hopefully help to
stave off bogus bug reports.
We also never had a great overview of event handling from an Item's
perspective; now it's a little better.
Followup to ab91e7fa02a562d80fd0747f28a60e00c3b45a01 and
a97759a336c597327cb82eebc9f45c793aec32c9
[ChangeLog][QtQuick][QQuickItem] When subclassing QQuickItem, you
should call setAcceptTouchEvents(true) if you need the item to receive
touch events. It will be required in Qt 6.
Pick-to: 6.0
Pick-to: 5.15
Task-number: QTBUG-87018
Task-number: QTBUG-87082
Change-Id: I1c7a43979e3665778d61949c9d37c1d085ed594b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
By showing the tableview, we can be sure that headerviews will be
visible even in the syncView has an empty model.
Fixes: QTBUG-87526
Change-Id: I68c8b119122a2d2f88c2afbeb2d6c71a83a3ce33
Pick-to: 5.15 6.0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider
Flickable {
Text {
TapHandler { gesturePolicy: TapHandler.ReleaseWithinBounds }
}
}
On press, TapHandler gets the exclusive grab. Now drag vertically.
The Text is short in stature, so your finger soon strays out of bounds
of the Text, likely before you have dragged past the drag threshold.
In this case, we want Flickable to continue to filter the move events
because of the fact that TapHandler is the grabber. If it was a
MouseArea instead of a TapHandler, it already worked that way; so this
makes behavior of handlers more consistent with that.
More specifically: QQuickPointerTouchEvent::touchEventForItem() now
generates a touch event even if the touchpoint is not within the bounds
of the given item, but is grabbed by one of that item's handlers. Until
now, we had that exception only if it was grabbed by the item itself.
tst_FlickableInterop::touchAndDragHandlerOnFlickable now always drags
the delegate at index 2 (the third one) from its upper-right corner,
upwards and to the left. The first drag goes outside the delegate's
bounds, but the Flickable/ListView/TableView filters and takes over
anyway (on the next drag), to prove that it is correctly depending
on the grab that the TapHandler (or DragHandler) took on press.
Pick-to: 5.15
Pick-to: 6.0
Fixes: QTBUG-75223
Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the property lineHeight is used to reduce the line height, either by
setting a proportional factor smaller 1.0 or a pixel size smaller than
the font size, the offset calculated in lineHeightOffset is not taken
in to account to calculate the height properties. But the offset is used
to position the the rendered text. In the current implementation the
property lineHeight does not have an effect on single line texts. This
change takes that into account and adds lineHeightOffset to all height
properties.
Fixes: QTBUG-88229
Change-Id: Iab7d9b39a4c7876c7c95e43be6846623c10b0607
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are legitimate cases for using the private class, the number one
case being Design Studio where QQuickRenderControl and QRhi are used
together. At the moment things work presumably because only member
variables are accessed, and that works even in builds that do not
have the member functions exported. Fix this up to be future proof.
Pick-to: 6.0
Change-Id: I054deb31607ca8c95fccb2f5988dde6f0a9c372a
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Pick-to: 6.0
Change-Id: Ic8b2fa8333fdc6aae051f3b2faa3a0c0ecad9ad5
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
|
|
| |
Just use a function because the private and impl classes for
QQuickShaderEffect do not have their own headers.
Change-Id: If5070aeb8c2b07b9b7e2cf3e16071ee2af2e368b
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
| |
Change-Id: Id542b473c1596f9933cdef747f7fe329988618d4
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Pick-to: 6.0
Change-Id: I05e3f804af3668235f97cebc54e1904a90092385
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Pick-to: 6.0
Fixes: QTBUG-88761
Change-Id: Ia5df65a4a09a7554a7d0cca4533f766cb5abe97b
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
| |
This ensures that the memory is freed reliably
Fixes: QTBUG-88807
Pick-to: 5.15 6.0
Change-Id: I841a5a2b226a69ce50975d95702a948857d1b54f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
In case of enabled accessibility, whenever the geometry
of a QQuickItem changes, accessibility module is notified
by a LocationChange event. This enables responding to this
by for example moving the accessibility frame on the screen.
Task-number: QTBUG-79611
Change-Id: I808e835384ef42bba2e9aabecf4be3cda07859fe
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
Since QEvent::clone() overrides return the type that they clone, calling
it on an already downcast pointer doesn't require another downcast.
Change-Id: Iba957f67a3b6c45cbd59e9978dc92ed5eb5db6c0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, on press when QQuickFlickable::filterPointerEvent() calls
captureDelayedPress() and will return true, it also accepts the event to
stop propagation. It becomes the grabber as a consequence of that.
On a future move event, when the drag threshold is exceeded while the
delayed press timer is still running, Flickable already has the grab
(but it accepts the event again), and QQuickFlickablePrivate::drag()
calls setKeepMouseGrab(true). In this case we still want to prevent any
children's DragHandlers from seeing the event, because a DragHandler
will also see that the drag threshold was exceeded and try to steal the
grab. A DragHandler can steal the grab only if there was no press
delay: then it sees the initial press because Flickable does NOT stop
event propagation (does not accept the event), so it can take a passive
grab and continue to wait for the drag threshold to be exceeded,
regardless of what else happens.
In case of multiple touchpoints, allPointsGrabbed() returns false if the
Flickable has only grabbed one point; but we want to avoid delivering
handlers in children just on the basis of that grabbed touchpoint being
within their bounds, even though other points may be delivered to
various handlers.
This fixes tst_FlickableInterop::touchAndDragHandlerOnFlickable.
The blacklisting of dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch
was bogus (it's in the mousearea_interop test).
Pick-to: 6.0
Task-number: QTBUG-86729
Change-Id: I9f0d42e97de4f4a3b4f7773800a8d59dc34a0553
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a mismatch for the cache key: sometimes using the original url
as specified in the QML code, sometimes using the resolved url (which has,
for example, a relative path expanded to absolute). Change this to be
consistent.
Pick-to: 6.0
Fixes: QTBUG-88673
Change-Id: I201750716d3ba6dbe73a4799ac56f26f9b8ec820
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
| |
Pick-to: 6.0
Change-Id: Id7193f64093c20bb798b6bc6fbf87f1ce41364d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the parent class (QWindow) has that property, QDoc does not
allow documenting properties from base classes. The documentation
for QQuickWindow::transientParent includes QML-specific information,
so use QDOC_PROPERTY macro in the header file to make the property
documentation visible.
Pick-to: 6.0
Change-Id: Ib281c776717e09e6929420c6173a520613356d91
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
lineCount is not reset when replacing a multi-line QML Text 'text'
property with an "" empty string. Also, the lineCountChanged signal is
not emitted
Pick-to: 5.15
Task-number: QTBUG-84458
Change-Id: Ic3c02e6a90e6675eadbaafc6af6ab0356ee98123
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem()
doesn't need to call item->mouseUngrabEvent() because all grab changes
are notified via the connection from signal QPointingDevice::grabChanged
to slot QQuickWindowPrivate::onGrabChanged(). But in this case,
MouseArea only accepts the event, rather than taking the grab itself.
Therefore at the time the grab is "stolen", there was not yet any
grabber, because grabbing is done after delivery. But we still need to
inform MouseArea that it's not getting the grab it expects to get, so
that it can reset its pressed state. But we don't want it to be
redundant (other tests are counting events, and we don't want repeated
ungrabs to show up in those); so now we have to track whether the item
on which we're about to call mouseUngrabEvent() has already gotten it.
This illustrates another problem with the tradition of accepting events
and being unclear about what it means. Grabbing is one thing, ending
delivery is another.
Amends a97759a336c597327cb82eebc9f45c793aec32c9
Task-number: QTBUG-55325
Task-number: QTBUG-86729
Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a QQuickWindow is deactivated, visiting every item in the entire
scene to tell them the news isn't very efficient, especially considering
that the only item that overrode this virtual function has been
QQMouseArea, throughout the lifetime of Qt 5. If it's important to
cancel grabs of MouseAreas, then it's equally important to cancel grabs
of MultiPointTouchArea, pointer handlers, etc. It should be OK to
delete the virtual function since it was never documented, and marked
\internal, so hopefully no users are depending on it.
The existing tst_QQuickMouseArea::pressedCanceledOnWindowDeactivate()
test continues to pass, which proves that the WindowDeactivate event
still has the desired effect on MouseArea.
Change-Id: I0109370aba14096fb7777a83cf1b6763ac58013f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: I3b2d1fbc4b62b501aa6ed748a692cb4bba261c5e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|