qt/qtdeclarative.git/src/quick/items/qquickflickablebehavior_p.h, branch dev Qt Declarative (Quick 2) Set explicit default security level of all files with default security 2025-09-17T13:31:14+00:00 Jan Arve Sæther jan-arve.saether@qt.io 2025-09-16T13:35:55+00:00 01cd43d30e3ca2c4dd94a4a4711604adb9417517 The files (folders) already processed are listed in each issue in epic QTBUG-134547 These files were processed half a year ago. In order to make it clear that all of these files are already processed, mark them with an explicit default security header. For the record, this was generated with this script: find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py in the folders listed in each subtask of QTBUG-134547 (add-cra-header.py only exist at my desktop, but it simply adds the default security header if it doesn't already have any existing security header) QUIP: 23 Fixes: QTBUG-134547 Pick-to: 6.10 6.9 6.8 Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> 
The files (folders) already processed are listed in each issue in epic
QTBUG-134547

These files were processed half a year ago. In order to make it clear
that all of these files are already processed, mark them with an
explicit default security header.

For the record, this was generated with this script:

find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py

in the folders listed in each subtask of QTBUG-134547

(add-cra-header.py only exist at my desktop, but it simply adds the
default security header if it doesn't already have any existing security
header)

QUIP: 23
Fixes: QTBUG-134547
Pick-to: 6.10 6.9 6.8
Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Flickable: Proportional wheel scrolling if deceleration is large 2023-06-12T15:38:52+00:00 Shawn Rutledge shawn.rutledge@qt.io 2022-09-30T10:46:18+00:00 b1766d9d629f61d824146e69f1f3b319cbee3d11 Many users have complained about scrolling via mouse wheel being more or less uncontrollable: it's very hard to scroll shorter distances, and multiple "clicks" of the wheel usually overshoot far beyond what was intended. It was possible to mitigate that by setting flickDeceleration, but then touch-flicking also became much more "sticky". So now we have the flickDeceleration property dedicated to touchscreen flicks only, with the default coming from QPlatformIntegration::FlickDeceleration. There's no QPlatformIntegration::StyleHint for mouse-wheel deceleration. We disable the old wheel-acceleration feature by default, because many users nowadays have fancier mice or touchpads that achieve the acceleration in their own way. That's achieved by having the wheel deceleration value set to 15000 by default, which would be quite "stiff" if it was applied to the timeline, but in fact is defined to mean that there will be no acceleration. If the default is changed to 14999 or less, we continue reusing the same animation timeline for both flicking and wheeling, and applying the same acceleration/deceleration as before. There's some risk that some users will miss the old behavior; so we add a new QT_QUICK_FLICKABLE_WHEEL_DECELERATION environment variable to allow the user to override the default (to something less than 15000). When acceleration is disabled (which it is by default), QQuickFlickable::wheelEvent() no longer calls flick(), but instead uses the timeline to move the contentItem directly. Includes a drive-by fix, that enables scrolling to continue, even after the contentItem has moved into an edge. This behavioral change makes sense now that the scroll movement is more predictable. fixup() will still be called, to trigger the rebound animation. This patch reduces the strength of wheelEvent scrolling, so it made small tweeks to tst_QQuickListView2::wheelSnap necessary. [ChangeLog][QtQuick][Flickable] When using a plain "clicky" mouse wheel, Flickable has historically applied acceleration: the faster you rotate the wheel, the faster it flicked. The default value of flickDeceleration was 5000, which felt hard to control, but changing it in QML affected touch-flicking and wheel behavior simultaneously. So now we decouple those: flickDeceleration only affects touchscreen flicking, and Flickable rather uses a new default value of 15000, which is defined to mean that scroll distance becomes directly proportional to QWheelEvent::angleDelta() * QStyleHints::wheelScrollLines() (where a "line" is 24 logical pixels, because Flickable does not have direct understanding of its contents). You can set the new environment var QT_QUICK_FLICKABLE_WHEEL_DECELERATION to a value from 1 to 14999 to restore wheel acceleration behavior from older versions; 5000 was the old value. Done-with: Oliver Eftevaag <oliver.eftevaag@qt.io> Done-with: Paul Olav Tvete <paul.tvete@qt.io> Task-number: QTBUG-35609 Task-number: QTBUG-80720 Task-number: QTBUG-82565 Fixes: QTBUG-97055 Fixes: QTBUG-106338 Pick-to: 6.6 Change-Id: I0645c08c9681f57bc749b4cc7f4d26507f5cb211 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> 
Many users have complained about scrolling via mouse wheel being more or
less uncontrollable: it's very hard to scroll shorter distances, and
multiple "clicks" of the wheel usually overshoot far beyond what was
intended. It was possible to mitigate that by setting flickDeceleration,
but then touch-flicking also became much more "sticky". So now we have
the flickDeceleration property dedicated to touchscreen flicks only,
with the default coming from QPlatformIntegration::FlickDeceleration.
There's no QPlatformIntegration::StyleHint for mouse-wheel deceleration.
We disable the old wheel-acceleration feature by default, because many
users nowadays have fancier mice or touchpads that achieve the
acceleration in their own way. That's achieved by having the wheel
deceleration value set to 15000 by default, which would be quite "stiff"
if it was applied to the timeline, but in fact is defined to mean that
there will be no acceleration. If the default is changed to 14999 or
less, we continue reusing the same animation timeline for both flicking
and wheeling, and applying the same acceleration/deceleration as before.

There's some risk that some users will miss the old behavior; so we add
a new QT_QUICK_FLICKABLE_WHEEL_DECELERATION environment variable to
allow the user to override the default (to something less than 15000).

When acceleration is disabled (which it is by default),
QQuickFlickable::wheelEvent() no longer calls flick(), but instead uses
the timeline to move the contentItem directly.

Includes a drive-by fix, that enables scrolling to continue,
even after the contentItem has moved into an edge.
This behavioral change makes sense now that the scroll movement
is more predictable. fixup() will still be called,
to trigger the rebound animation.

This patch reduces the strength of wheelEvent scrolling, so it
made small tweeks to tst_QQuickListView2::wheelSnap necessary.

[ChangeLog][QtQuick][Flickable] When using a plain "clicky" mouse wheel,
Flickable has historically applied acceleration: the faster you rotate
the wheel, the faster it flicked. The default value of flickDeceleration
was 5000, which felt hard to control, but changing it in QML affected
touch-flicking and wheel behavior simultaneously. So now we decouple
those: flickDeceleration only affects touchscreen flicking, and
Flickable rather uses a new default value of 15000, which is defined
to mean that scroll distance becomes directly proportional to
QWheelEvent::angleDelta() * QStyleHints::wheelScrollLines() (where a
"line" is 24 logical pixels, because Flickable does not have direct
understanding of its contents). You can set the new environment var
QT_QUICK_FLICKABLE_WHEEL_DECELERATION to a value from 1 to 14999 to
restore wheel acceleration behavior from older versions; 5000 was
the old value.

Done-with: Oliver Eftevaag <oliver.eftevaag@qt.io>
Done-with: Paul Olav Tvete <paul.tvete@qt.io>
Task-number: QTBUG-35609
Task-number: QTBUG-80720
Task-number: QTBUG-82565
Fixes: QTBUG-97055
Fixes: QTBUG-106338
Pick-to: 6.6
Change-Id: I0645c08c9681f57bc749b4cc7f4d26507f5cb211
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
QtQuick: Fix conflicting definition of MinimumFlickVelocity in CMake Unity (Jumbo) builds 2023-02-07T18:23:12+00:00 Friedemann Kleint Friedemann.Kleint@qt.io 2023-02-03T10:01:31+00:00 be815997238f38d6a0672c1cb9f2ecb995ce1d13 Move constant MinimumFlickVelocity to a common header and prefix it to avoid clashes in static builds. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ic4178a3e7c1ea930a711c4e04f26edda19ad3efb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> 
Move constant MinimumFlickVelocity to a common header and prefix it
to avoid clashes in static builds.

Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: Ic4178a3e7c1ea930a711c4e04f26edda19ad3efb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Get flickThreshold, flickMaxVel and flickDeceleration from platform 2023-01-11T19:13:18+00:00 Shawn Rutledge shawn.rutledge@qt.io 2014-07-31T16:26:59+00:00 84d69e4695c179e595d24928a6480852d7f5186f Now they are slightly more configurable instead of obscure hard-coded constants. As a drive-by, remove unused header includes. Task-number: QTBUG-35608 Task-number: QTBUG-35609 Task-number: QTBUG-97055 Change-Id: I092009477f5f58ad5952cf4650353bf8b05521ed Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> 
Now they are slightly more configurable instead of obscure hard-coded
constants.

As a drive-by, remove unused header includes.

Task-number: QTBUG-35608
Task-number: QTBUG-35609
Task-number: QTBUG-97055
Change-Id: I092009477f5f58ad5952cf4650353bf8b05521ed
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Use SPDX license identifiers 2022-06-11T06:05:15+00:00 Lucie Gérard lucie.gerard@qt.io 2022-05-13T13:12:05+00:00 0dc4fd240a2897c5c443a0ef6d84c416843e4938 Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> 
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.

Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
PathView: reduce velocity by linear decay model if release is delayed 2019-09-12T16:54:12+00:00 Shawn Rutledge shawn.rutledge@qt.io 2019-09-10T13:26:56+00:00 3df387d63421f09533ab72e2a73fb5d259693120 That is, from the time between the last mouse move event to the mouse release, the velocity will be linearly discounted/depreciated until it reaches 0 at QML_FLICK_VELOCITY_DECAY_TIME, which is currently 50 ms. 50 ms seems like a long time if the user meant to flick and release immediately (in practice it might be more like 4 ms), and also a short time if the user meant to "dwell" before releasing. If we try to translate the fake physics to real physics, this would be approximately equivalent to saying that if you slide a flat plate on an air hockey table with one finger, and then stop suddenly, its momentum _would_ cause it to keep moving under your finger for up to 50ms (except that it doesn't, because our timeline doesn't "tick" until after the release); and yet if you hold it for longer than 50ms, it will stop right on the spot. That's not quite realistic, but feels OK for fake physics (like the rest of the physics in Qt Quick). Also add the qt.quick.pathview logging category, which will just log the velocity calculations for now (but is intended for anything else in PathView that seems worth logging later on). Task-number: QTBUG-77173 Task-number: QTBUG-59052 Change-Id: Ie86f18d3b3305874b698c848290e0fd3beda94de Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> 
That is, from the time between the last mouse move event to the mouse
release, the velocity will be linearly discounted/depreciated until it
reaches 0 at QML_FLICK_VELOCITY_DECAY_TIME, which is currently 50 ms.
50 ms seems like a long time if the user meant to flick and release
immediately (in practice it might be more like 4 ms), and also a
short time if the user meant to "dwell" before releasing.

If we try to translate the fake physics to real physics, this would be
approximately equivalent to saying that if you slide a flat plate on an
air hockey table with one finger, and then stop suddenly, its momentum
_would_ cause it to keep moving under your finger for up to 50ms (except
that it doesn't, because our timeline doesn't "tick" until after the
release); and yet if you hold it for longer than 50ms, it will stop
right on the spot.  That's not quite realistic, but feels OK for fake
physics (like the rest of the physics in Qt Quick).

Also add the qt.quick.pathview logging category, which will just log
the velocity calculations for now (but is intended for anything else
in PathView that seems worth logging later on).

Task-number: QTBUG-77173
Task-number: QTBUG-59052
Change-Id: Ie86f18d3b3305874b698c848290e0fd3beda94de
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Remove remnants of blackberry platform support 2017-01-16T17:10:14+00:00 Robin Burchell robin.burchell@crimson.no 2017-01-16T14:51:58+00:00 373cdc297f343932218782d3587b98af5f8ccc53 The last remnants were removed from qtbase in 5.7 making this all dead code, so match here too. Change-Id: I10f3f1c614562f2a97ade7cdf5002065d6f79e07 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> 
The last remnants were removed from qtbase in 5.7 making this all dead code,
so match here too.

Change-Id: I10f3f1c614562f2a97ade7cdf5002065d6f79e07
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Updated license headers 2016-01-19T14:53:18+00:00 Jani Heikkinen jani.heikkinen@theqtcompany.com 2016-01-19T09:38:36+00:00 45bd04ba73bd3e71c070e5724535ba87f6771323 From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com> 
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/

Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)

Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Add missing "We mean it" comments to private headers. 2015-10-06T15:39:36+00:00 Friedemann Kleint Friedemann.Kleint@theqtcompany.com 2015-10-05T08:45:54+00:00 933cff33cb53c88ec5a11b8f53955054c648e21b Task-number: QTBUG-48594 Change-Id: Ifc207938de7f0c8995fc712df92665f222612647 Reviewed-by: Alan Alpert <aalpert@blackberry.com> 
Task-number: QTBUG-48594
Change-Id: Ifc207938de7f0c8995fc712df92665f222612647
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
Update copyright headers 2015-02-12T10:28:11+00:00 Jani Heikkinen jani.heikkinen@theqtcompany.com 2015-01-28T11:55:39+00:00 c5796292adf7cb7f2ce6f95fb83a9da89ecaa730 Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9 Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com> 
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.

Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>