The weight in QFont is an integer, allowing you to request a font
of any weight given the predefined scale. In Qt Quick, however, you
were limited to the predefined values.
This is done in Qt 6 because it breaks conversions from string to
weight, as the change in the autotest illustrates.
[ChangeLog][Font] Made Font.weight an integer value rather than limit
it to a predefined set of weights. As a side effect, conversion from
strings to font weights are no longer supported.
Fixes: QTBUG-80402
Change-Id: Ifbe9a0e608b63bfa93bb54999b0b3c1851ccfa88
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Being able to set the name of a FontLoader seems to have been made to
allow for some alternative coding patterns, but it doesn't really
provide any convenience over other ways of customizing font names,
and it definitely adds confusion for users, as well as as a possible
race condition if both the source and name of the same FontLoader is
set at unpredictable times.
[ChangeLog][QtQuick] FontLoader.name property has been made read-only
to reduce confusion about its use and precedence over conflicting
properties.
Fixes: QTBUG-80031
Change-Id: I0dd0e76ff376402c0b458ed7e5c57ec017bbc92d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The glyphs between two text blocks that have different text format
will be rendered twice, and in this case the rich text will be display
incorrectly.(e.g., the first text block is a superscript and the
second is a normal text)
Fixes this by reduce the redundant rendering of glyphs between two
differently formatted text blocks
Fixes: QTBUG-80759
Change-Id: I51ca3f7df1ad368d28df9beb6124a87bf50f0e01
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When visible items become invisible, ListView will try to cache
them and redisplay these items if necessary. However, we can't
cache items when changing to a new model, since the old one will
be deleted later
Fix by adding a flag to let ListView know we are clearing items
and prevent cache unnecessary items
Fixes: QTBUG-80203
Change-Id: I50dcd3f0586c93496b143bdad0e59751360501a8
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The behavior of QDoubleValidator has changed in qtbase, in commit
3359b29c99581f52acf033489ad35884a01ccac8.
"12," is not an acceptable input anymore. Adapt the test to
reflect this.
Change-Id: I0daaae2f84325b911263ee0545523ce3cc322049
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
The implementation for the X mask would accept any printable
character. Since that includes the blank character, there was no
difference in behavior between the requiring X and optional x: both
would allow the input to be unset, i.e. blank.
This change should be seen in conjunction with the doc improvement
qtbase:da0af1e and the corresponding change to the QLineEdit widget,
where the same input mask handling code is duplicated.
This patch series also concludes the old task questioning whether
text() should strip blanks even when they are valid input (answer:
yes, continue to do that), and so a couple of XFAILS was removed from
the autotest.
[ChangeLog][QtQuick][TextInput] Inputmask X character now requires non-blank input.
Task-number: QTBUG-76320
Change-Id: I606ae04259f29f748b3ce604048c6eb6f10c2ff9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
From before we would bail out early from the rebuild process if we
detected an empty table. A result from this is that we left
both contentWidth and contentHeight unchanged.
This patch will set an empty content size when the table is
empty. The effect will be that the user cannot flick the view
around based on the old size.
Fixes: QTBUG-80505
Change-Id: I3ac080476269fd5906ce79fa007eabb59b5ff4b1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
As it stood, we would wait to release loaded items until we started the
rebuild process, if the old model was a DelegateModel. But at that time,
the model would alread have been changed, so we would release the items
by calling out to the wrong model.
This patch will ensure that we always release the items immediately when
syncing the model, which will also cover the case when the model is a
DelegateModel.
Fixes: QTBUG-80570
Change-Id: I1b06011f4795727d04d9cd8c20381f65552b8fe8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Normally you either assign a model to TableView that
already has a delegate (or don't need one), like
DelegateModel or ObjectModel. Or instead you assign
a QAIM model and a delegate directly. But if you
assign both a delegate and an ObjectModel, TableView
would be confused, and ignore the assigned model
and instead create an internal wrapper model that
ends up empty.
This patch will ensure that we don't create a wrapper
model in such cases, but instead forward the
delegate to whichever model is assigned, even
if it ends up as a no-op for models that don't
use one.
Task-number: QTBUG-80534
Change-Id: Idd220df08617c379dc7808ee1f41c862b78cc201
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Change 631ef67458 fixed a bug that wrote a wrong error message
to the console. But there is a test that checks for that message
that was also wrong (but for some reason the test passed in the CI,
but it has started to fail locally).
This patch will ensure that the test don't fail because we check
for a wrong error message.
Change-Id: I27e16b0f4aa6a0ffeb8c42f846c344436a41ad3c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The scenario:
- mouse press: MouseArea grabs; DragHandler gets a passive grab
- drag a little: DragHandler's drag threshold is exceeded
- drag some more: DragHandler tries to take the exclusive grab
This grab takeover succeeded before, because although MA has
keepMouseGrab(), the event being delivered is a touch event,
and MA does not have keepTouchGrab().
If this happens while QQuickWindowPrivate::touchMouseId is the
same touchpoint that the DragHandler is trying to grab, it should
not succeed, because we honor the keepMouseGrab() flag. I.e.
keepMouseGrab() implies keepTouchGrab() whenever the touchpoint
under consideration is currently the touch-mouse.
On the other hand, if a DragHandler is used on some item inside
a Flickable: on press, the Flickable grabs right away (it has a
bad case of FOMO), but the DragHandler just gets a passive grab.
When the drag threshold is exceeded, DragHandler must be able to
steal the grab from Flickable, because Flickable was just being too
aggressive. So now we have the rule that if the Item it wants to steal
the grab from is a parent of the type that filters all events,
it's OK to ignore the keepMouseGrab() flag and steal anyway
(as it did before this patch).
Fixes: QTBUG-79163
Change-Id: I2b3f175bea867cb737357857657653b0a7b83995
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Multiple TapHandlers must be able to react to multiple touchpoints.
Often when multiple touchpoints are in contact, some of them will be
stationary. In that case TapHandler should not give up its active
state, which is the result of returning false from wantsEventPoint().
This partially reverts commit dcc7367997.
Fixes: QTBUG-76954
Change-Id: I836baf771f09d48be8d032472b0c3143e8f7f723
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
As the variable was manually set to -1 beforehand, we would never emit
the change signal, leaving bindings stale. However, simply removing the
assignment would lead to not triggering the signal when currentIndex was
0. So now we set it to -2, which cannot happen in any other place.
Note that QTBUG-64998 was already mostly fixed due to earlier changes
fixing the currentItem part, only currentIndex was still broken
Fixes: QTBUG-68232
Fixes: QTBUG-64998
Fixes: QTBUG-63422
Change-Id: I885e06f1e258e67c3368d017bf79bff760440863
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Consistently check that job->data is not null before derefencing it.
Fixes: QTBUG-80510
Fixes: QTBUG-79937
Change-Id: I894503ddd2254814463073cc12f8365641efc689
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
If the header or footer positioning is Overlay or PullBack, the list
delegates appear to scroll underneath it. The header or footer can
contain interactive content. If a mouse or touch press happens to
"fall through" that, it should not be possible to drag the ListView
contents from there.
[ChangeLog][QtQuick][ListView] ListView no longer allows the user to
press on an Overlay or PullBack header or footer and start scrolling,
but only on the content delegates.
Fixes: QTBUG-74046
Change-Id: I4d06c789286be2691d098aeebb10a57b2a335744
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
When moving an item from ObjectModel A to ObjectModel B, polishes are
scheduled for the respective ListViews in order: the ListView for A
first, and then the ListView for B. However, when it comes time to
do the actual polishing via updatePolish(), the list of items is
traversed backwards. This means that the following calls
var item = objectModelA.get(0)
objectModelA.remove(0, 1)
objectModelB.insert(0, item)
will result in updatePolish() being called for ListView B first, and
then ListView A. As a result of this, setCulled(false) will be called
by ListView B (since the item is now visible within it), followed by
ListView A calling setCulled(true) (since the item is now no longer in
it).
As there is no way for these models to know about each other (and it's
not feasible to store refcounts in QQuickItemPrivate::extraData, since
ObjectModel is in QtQml.Models, which can't know about QtQuick), this
patch makes ListView check if the item is parented to its contentItem
before culling it. This prevents it from hiding items which are no
longer shown in its view.
Change-Id: If50614ebc269fae875195bbc63c0c04dab237775
Fixes: QTBUG-67986
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When the grabbed Item is released and then grabbed again,
if ungrabMouse () is called, the animation stops. In order to
avoid this, when ungrabMouse () is called, if offset is different,
it is modified to animate.
Task-number: QTBUG-79592
Change-Id: I61cbd4dad90643722f12480f0dab3859ce116af8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Change 35fdf3a7b7 added a binding to a function in one of
the QML files used for testing (plaintableview.qml). The
problem is that this file is also used from other places
where we wrap a QSharedPointer that points to the model
inside a QVariant. And when assigning that variant to
a TableView, the QML binding will see the QSharedPointer, and
not the model it points to. And hence complain that the
model doesn't have the API that is exported from the
model.
The easy fix is to just create a new QML file for the
new test added, that has the binding, but assigns
a QVariant that wraps the model directly without
usign a QSharedPointer.
Change-Id: Ic2b77426c2d700479a9b5f4007384661e2ca0801
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This patch will implement delegate item recycling in
ListView. The API will be the same as used in TableView, except
that it will be off by default since the behavior of a delegate
that is reused is not compatible with legacy applications
which were not written with this in mind.
Most importantly:
- Component.onCompleted will only be called on a delegate the
first time it's created, and never when it's reused.
- Any user-declared properties in the delegate (that is, not
model roles, index, etc) will not be cleared or updated when an
item is reused. The application must do this manually upon
receiving the pooled or reused signal in the item.
[ChangeLog][ListView] ListView now has support for reusing delegate
items. This can be switched on by setting the reuseItems property of
ListView to true.
Task-number: QTBUG-80507
Change-Id: I68cc8300b050e4a1f89feebb1d31a2fd9189c793
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This implements Michael Brasser's suggestion in the bug report.
As there do not seem to be other bug reports related to the
fixupPosition change, this might already be enough.
Fixes: QTBUG-66163
Change-Id: Iee45621ff7081b280626f4a81dab9bd36a7ea6b7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
If we have a proxyObject, we need to use that one for reading proxy
values. Otherwise the read operation will crash.
Fixes: QTBUG-80420
Change-Id: I88cd5499802bff1aea2e43da9ab61d6565ab7ede
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If you did not specify a blank character (e.g. "; " as suffix) it would
internally add that suffix to the property, resulting in that the
property itself actually got a "; " suffix even when not specified.
So when setting the same input mask again, it wouldn't match the
existing inputMask property, and it would emit inputMaskChanged again.
Change-Id: Ia47d63d56c640b4be9d6d0a704ddfaff01befbdb
Fixes: QTBUG-80190
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If an event handler (such as DragHandler) takes the exclusive grab
of a touchpoint that MouseArea had already grabbed as a synth-mouse,
it should react in the same way as if its grab of the actual mouse was
stolen: release the pressed state, etc.
Fixes: QTBUG-77624
Change-Id: I51f4fb253f7d0377be421c23e617942507616e72
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
We ignored them because we assume that if a touch event is sent first,
the MultiPointTouchArea will handle it; and then if a synth-mouse event
is sent afterwards for some reason, it's irrelevant to MPTA. However:
1) A synth-mouse event should not actually be sent, because MPTA accepts
the touch event. 2) If Flickable is used with pressDelay set, Flickable
will send the delayed press in the form of a mouse event (it does not
know how to replay a touch event at all). So if MPTA is used in a
ListView delegate for example, it's necessary for MPTA to react to a
synth-mouse event during replay. In both the press delay replay
and QTabletEvent scenarios, the mouse event has source() set to
MouseEventSynthesizedByQt, so MPTA needs to handle those events.
After a synth-mouse event during replay, MPTA can still receive an
actual touch release, which thoroughly confuses its pre-existing logic.
In that case it helps to check whether the touchpoint ID is the same as
QQuickWindowPrivate::touchMouseId, handle the release of that point, and
also release the internal synthetic _mouseQpaTouchPoint which was
remembered from the mouse press.
Fixes: QTBUG-75750
Fixes: QTBUG-78818
Change-Id: I8149f8b05f00677eb07a2f09b725b1db5f95b122
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The raw index doesn't take the filter group into account.
Fixes: QTBUG-78297
Change-Id: Ie6514c8acdc380fe3f8f267d02335afc357abd17
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Joshua GPBeta <studiocghibli@gmail.com>
Otherwise we would set the same object as extraObject and as
contextObject. That spells trouble when tearing down the context.
Fixes: QTBUG-79958
Change-Id: I97fd0bf111304d06cff35eda46d4b4c6eefdaccc
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QQmlTableInstanceModel implements canFetchMore and fetchMore functions,
but these are not called at any point in QQuickTableView. This change
checks if additional data can be fetched when atYEndChanged signal is
emitted.
Fixes: QTBUG-78273
Change-Id: I49b41b09d9a218826b34f32cd9fe4724a6097b52
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When reusing a delegate item, it can sometimes happen that the item
ends up being reused at the same location in the table as it had
before it was pooled. And in that case, we don't emit changes to
index, row and column since they technically didn't change.
The problem is that the model might have changed in-between, e.g if
a row has been removed. And in that case, row and column will, even
when unchanged, point to other parts of the model. So all bindings
needs to be reevaluated to ensure that the values they use are
refreshed.
This patch will therefore ensure that we always emit changes to
the mentioned properties when an item is reused, regardless if
they change or not.
Fixes: QTBUG-79209
Change-Id: Icec201a43a30b9f677303fbf652baf6487621deb
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
[ChangeLog][AnimatedSprite] Add finishBehavior to allow a sprite to
finish on the last frame.
Task-number: QTBUG-59090
Change-Id: Id45e879cdc4905f43e2ac3cb2529181390d47aab
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
We now print a warning and try to gracefully handle it
Change-Id: I66e79fe918808f5fede78a23df50e9e95b7b832d
Fixes: QTBUG-67204
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
An assert will trigger if forceLayout() is called while the model is
being reset. The reason is that the forceLayout() schedules a relayout
which assumes that the size of the model hasn't changed. But while
layouting, it will try to fetch data from the model according to the
old size, which will trigger an assert.
This patch will add an extra path to forceLayout() that checks if the
size of the model has changed, and if so, schedule a complete
rebuild instead of just a relayout.
Fixes: QTBUG-79395
Change-Id: If61658912d9e90c1a5aef9bc28083da20fa6ec76
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
This allows types to attach an accessible name to an item, so long as
the user hasn't done so themselves.
Task-number: QTBUG-66583
Change-Id: I04f26815ffeaf1198fee25dc414253de8b8dfabe
Reviewed-by: Liang Qi <liang.qi@qt.io>
Previously there was no way to know what area is occupied by each line
in a QML Text element.
This commit adds new API to expose implicitWidth and isLast
on QQuickTextLine for use in the lineLaidOut signal.
It also adds improved documentation to the lineLaidOut signal and
an example usage of the new API to the text layout example.
An example use case of the new API is eg. to allow embedding
timestamps and indicators within a text paragraph, to enable
creating more efficient layouts.
[ChangeLog][QtQuick][Text] Added new API that exposes implicitWidth,
and isLast on the QQuickTextLine for use in the lineLaidOut signal.
This allows the user to layout other items relative to the lines
of text.
Fixes: QTBUG-78277
Change-Id: Ibc754db17c78efb01468106aba32e30d70d2f4df
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
For attached property objects, qmlEngine will not return an engine.
However, QQuickDragAttached's parent is the object to which it is
attached, and from that one we can get the engine.
Fixes: QTBUG-72045
Change-Id: I40748dd11ea3eb4604c37e932b2cfd3baad6fd1f
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Calling (de)refWindow can trigger QQuickItem::windowChanged, which in turn
can call a user defined windowChanged handler. If that signal handler
were to call setParentItem, we would encounter an inconsistent state:
The item already has its parent set, but that parent would lack the item
in its children list (as we would only call refWindow at a later point).
Fixes: QTBUG-79573
Fixes: QTBUG-73439
Change-Id: I46adaa54a0521b5cd7f37810b3dd1a206e6a09c6
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Preparing for the extraction of QGuiShortcut, the shortcut
feature will changed to follow the convention of using
QT_REQUIRE_CONFIG(shortcut) in the affected class headers.
Add the required exclusions to prevent compile errors
when disabling shortcuts.
Task-number: QTBUG-76493
Change-Id: Icad95584ae12aa97a56b56ef27206cef1b1ba48f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Removed dependencies.yaml because we don't use it yet in wip/cmake.
Fixed conflict in qmlcachegen.cpp.
Change-Id: Ie1060c737bee1daa85779903598e5b6d5020d922
ParentChange does floating point math in doChange to calculate the
correct position. Unfortunately, while doing the conversion, we
accumulate rounding errors in the presence of rotations.
Those can lead to visual glitches, as observed in QTBUG-68176.
This patch avoids the issue by storing the old values and resetting to
them in restore.
Fixes: QTBUG-68176
Change-Id: I6ebe1ccbc601838aa664cdc723e0cd58c95e785a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Previously, an active drop target would remain the drop target until the
drag left it's area, or entered a child item that accepted a
DragEnterEvent, even if the drag entered a drop target with a globally
higher z-order from a different subtree.
When moving to an item with a higher z-order, the DragEnterEvent is
now sent to the new drop target before DragLeaveEvent is sent to the old
drop target. There can now only be one drop target. If an item is the
current drop target and a higher z-order child accepts the DragEnterEvent,
the parent is no longer a drop target.
Fixes: QTBUG-30305
Change-Id: I7b985d6317be70867e7727222a4cd44ace7559e6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This is a very similar fix what's been done to the widgets to fix
QTBUG-48325. In QQuickWindow there is added the sending of
a ShortCutOverride even when a non-spontaneous KeyPress event
is received.
Task-number: QTBUG-78304
Change-Id: Icb267e611248460533f20e84deef71da6b481cd2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
It looked a bit odd that the DelegateModel delegate property was not a
notifying property. Adding the delegateChanged signal makes it easier
to update the view when this happens. The previous approach of removing
all delegates and adding all new ones resulted in the view losing its
currentIndex and often scrolling to a different place. It's also nice
to reduce the number of d-> indirections by adding the
QQuickItemViewPrivate::applyDelegateChange() function, so that we just
need one indirection to call it, and then it updates all the internal
stuff in one place.
Done-with: Frederik Gladhorn
Done-with: Joni Poikelin
Fixes: QTBUG-63477
Change-Id: I2d17fd11ff4a2fcb20968a7182dd2c403abb715a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QTBUG-78926 is about failing to emit the movingChanged signal. The
test verifies that e2df4233a7 fixed it.
While we're at it, might as well verify a few more signals in this test
scenario where we flick the PathView at various speeds and then stop
the flick by clicking.
Fixes: QTBUG-78926
Change-Id: I1253dfcd88a63abdbdd280dd9097b484a93cc491
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
A side effect of 8fd398c9d2 is that it
became possible for the highlight to stop between items, rather than
snapping to a specific item, if the user taps, clicks or drags an
additional time while the movement is ongoing. That was because it
didn't get a mouse grab, so it missed the release event.
QQuickPathViewPrivate::handleMouseReleaseEvent() needs to take care of
the snapping behavior after the user stops dragging. This only affects
behavior in the case that the PathView is already moving and the mouse
is pressed again: we assume the user wants to alter the PathView's
velocity, not interact with any delegate inside or with any parent item.
Task-number: QTBUG-77173
Task-number: QTBUG-59620
Change-Id: I7b2f69a6ef8d8022d7c917a5bf9e8fb40c8848db
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit e2df4233a7)
QQuickListViewPrivate::fixup() seems to only do "fixup" if
moveReason != QQuickListViewPrivate::SetIndex
By default, moveReason is set to Other. In the snippet given in
QTBUG-77418, this is why the highlight was respected when resizing the
ListView initially. However, after the currentIndex was changed,
moveReason was changed to SetIndex. When we then resized the ListView, it
still had the value SetIndex, and would fail to "fixup" properly.
Since the ListView preferredHighlightBegin is bound to width, we should
set moveReason to Other in the property setters that are related to
highlight. This is then consistent with how setCurrentIndex() does it (it
similarly sets d->moveReason = QQuickItemViewPrivate::SetIndex;)
Change-Id: I7edf77fc977e8c7e3fc656ff5bb22b4dd01afbe4
Task-number: QTBUG-77418
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We don't want to mix multiple modules in the same library anymore.
QtQuick should only contain types to be registered under QtQuick.
Otherwise we cannot automatically generate the type registrations.
Change-Id: I6a8e20fe8f7d01600232439a10168ef4298fc6b4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Qt Quick will not receive "uninteresting" stationary touchpoints, but
only those in which some property has changed. So MultiPointTouchArea
should react to stationary touchpoints in the same way as if they moved,
so that UIs can react to changes in touchpoint velocity, pressure etc.
And QQuickWindow has to be willing to delivery stationary touchpoints
to make this possible. However when a QTouchEvent is customized for
delivery to a specific Item, by including only the touchpoints that
are inside the Item, then if those touchpoints are all stationary,
the event only needs to be delivered if at least one of them is
an "interesting" stationary touchpoint. So we need to depend on
a new per-touchpoint flag that QGuiApplication will set when it
discovers that some property of the touchpoint has changed. That is
QTouchEventTouchPointPrivate::stationaryWithModifiedProperty.
Fixes: QTBUG-77142
Change-Id: I763d56ff55c048b258dca40d88283ed016447c35
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Change 5d995ae122 did not make the actual
QQuickImageBase::currentFrameChanged signal accessible to the Qt Quick
2.0 revision. Normally the QML engine would implement a JS
onCurrentFrameChanged handler by connecting to the currentFrame
property's frameChanged notifier signal; but in this case it tried to
connect to the explicit QQuickImageBase::currentFrameChanged signal
instead (because the name is a better match), and failed because of the
revision. So we need another duplicate unrevisioned signal
QQuickAnimatedImage::currentFrameChanged for use when the import is less
than Qt Quick 2.14.
As pointed out during review, an autotest for the revisioning is good to
have anyway.
Fixes: QTBUG-78713
Task-number: QTBUG-77506
Change-Id: I121508acac81d47e3c0a4c0ed12257c10b30970b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If enabled is false, then containsMouse will not become true when
hovering on mousearea, even if hoverEnabled is true. However when an
invisible mousearea become visible, the value of enabled isn't
checked. In this case, the value of containsMouse is not affected by
enabled.
[ChangeLog][QtQuick][QQuickMouseArea] containsMouse property will
not become true when the an invisible mousearea become visible, if
the enabled property is false or its parent item is not enabled
Fixes: QTBUG-77983
Change-Id: I923bdcf3eda813aea51a04515d530093d6eb77b2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
A side effect of 8fd398c9d2 is that it
became possible for the highlight to stop between items, rather than
snapping to a specific item, if the user taps, clicks or drags an
additional time while the movement is ongoing. That was because it
didn't get a mouse grab, so it missed the release event.
QQuickPathViewPrivate::handleMouseReleaseEvent() needs to take care of
the snapping behavior after the user stops dragging. This only affects
behavior in the case that the PathView is already moving and the mouse
is pressed again: we assume the user wants to alter the PathView's
velocity, not interact with any delegate inside or with any parent item.
Task-number: QTBUG-77173
Task-number: QTBUG-59620
Change-Id: I7b2f69a6ef8d8022d7c917a5bf9e8fb40c8848db
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
We need drag threshold to be adjustable on each handler instance instead
of relying only on the system default drag threshold. For example in
some use cases DragHandler needs to work with a threshold of 0 or 1 to
start dragging as soon as the point is pressed or as soon as the point
is moved, with no "jump", to enable fine adjustment of a value on some
control such as a Slider.
This involves moving the dragOverThreshold() functions that handlers are
using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that
they can use the adjustable threshold value.
Task-number: QTBUG-68075
Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
This mirrors the behavior in other parts of QML where writing to a
property in imperative code breaks the binding.
Change-Id: Id19eef17a3c5e77bc4c2772bd749b38c732606a8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Ensures that items created in a function are destroyed upon failures
in that function, and results in less code.
Change-Id: I62b3b7c3a19dbb2128c5c45bdc7adf4fe80df70d
Reviewed-by: Liang Qi <liang.qi@qt.io>
This changes the accessibile properties in the sectionDelegate:
If the sectionDelegate contains requiredProperties, "section" will not
be injected into a newly created parent scope.
Instead, the section property of the delegate will be set if it exists.
Change-Id: I34b04d08d2f80af7ea53fd722f08be0f9aea6e72
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If a delegates declares a required property of a given name, and that
name exists as a role in the model, we set the property accordingly.
The same holds true for the special properties that come from the
QQmlDelegateModel like "index" and "model".
All roles are still injected into scope and thus accessible;
changing this in Qt5 would be tedious or even impossible while still
maintaining backwardscompatibility with delegates that do not use
required properties.
Change-Id: I4f388ba549c42f1ff9822bdb3b8357c4d45e4b66
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
[ChangeLog][QtQml]
"required" is now a (contextual) keyword in QML, and users can
mark properties with it to specify that those properties must be set
when the component gets instantiated.
This can be done either declaratively via standard property
bindings from QML, or imperatively by using the functions to set initial
properties (QQmlCompoent::setInitalProperties and related functions in
C++, Qt.createObject, Loader.setSource,... in QML/JS).
Logic has been added to QQmlComponent::create and the various QQmlIncubator
classes to verify that the required properties were set. If properties
marked as required are not set, a warning will be printed at runtime,
and the component will not be created.
Change-Id: I8e38227fc8f173b053b689c1597dc7fd40e835e7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The autotest in 811b15bd16 only tested
what happens if the vector of polygons is passed via a QVariant to the
PathMultiline paths property. But the intention (as documented) was to
literally support an object with Q_PROPERTY(QVector<QPolygonF> paths ...)
and binding that paths property to PathMultiline.paths. In that case
it appears in QQuickPathMultiline::setPaths() as a QVariant<QJSValue>,
canConvert<QVector<QPolygonF>>() returns false, then
canConvert<QVariantList>() returns true. Nevertheless each variant
in the QVariantList is a QPolygonF, as expected. So we need another
check to detect this case. Also added a test specifically for that.
Fixes: QTBUG-77929
Change-Id: I84d0a45326d5f007b8ba3cc9bb1fbccf0345d812
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
If a C++ model object can make a vector of vectors of points available
directly, and it is bound to a PathMultiline's paths property to provide
the view layer, it's a waste of time to convert it to a QVariantList of
QVariantLists and back again. Changing the type of the property to
QVariant instead of QVariantList enables an extensible set of supported
types: all those that make sense.
Fixes: QTBUG-77929
Change-Id: If749c2171173e7b9933fc9ecdf6d2741dc1c7500
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
If a C++ model object can make a vector of points available directly,
and it is bound to a PathPolyline's path to provide the view layer, it's
a waste of time to convert it to a QVariantList and back again. Changing
the type of the property to QVariant instead of QVariantList enables an
extensible set of supported types.
Task-number: QTBUG-77929
Change-Id: I2453b59e047ec3310070e943f6934c9ddcd1ffaa
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
If the alpha value for the background color of a text element is 0,
we don't need to create a rectangle node to represent it, as the
rectangle will be invisible anyway.
[ChangeLog][QtQuick][QQuickTextNodeEngine] don't create a new
rectangle node as the background of text, when the alpha of it is
0
Fixes: QTBUG-76137
Change-Id: I40c624ee8f61740fd07e7d3751a78b6224882913
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The current logic was based on the idea that if both rowHeight-, and
columnWidthProveders were set, we didn't have to relayout the items
at the end of a rebuild. Because in that case, the row and column sizes
would already be correct after the initial load.
This assumption turns out to be false, because the providers are
allowed to return -1 to signal that the size of a row or column should
use default values (meaning, calculated by TableView). And for those
cases, we need to do a relayout at the end of a rebuild.
Fixes: QTBUG-77074
Change-Id: I0e0f2fdca1cfa9e98f2a0a2b227c3715c16a70f9
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
QTestLib assumes that the double click interval is below 500ms. Therefore
it adds a 500ms delay after all synthesized single- and doubleclick
releases to prevent unintentional synthesizing of double click events.
This has two unfortunate side-effects:
1. If the double click interval is smaller than 500 ms, it is not possible
to synthesize a triple click. (Triple clicks are used for selecting
paragraphs in text). This is why the workaround in the block (if clicks
==2) was needed.
2. If the double click interval is bigger than 500ms we might still
accidentally trigger a double click event with two successive single click
events, so it doesn't even work reliably for that case (!). Therefore, the
hardcoded 500ms in QTestLib should probably be revisited.
Anyway, to fix this test we therefore have to cancel the 500ms delta
QTestLib adds in order to properly synthesize the triple click by
adjusting the internal QTest::lastMouseTimestamp.
Task-number: QTBUG-77389
Change-Id: Ic738f51b294270ddf99b6d91d256f6ec4b34d039
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
There are various problems on QEMU: color depth may not be 32-bit,
and for some reason grabWindow isn't always working.
Task-number: QTBUG-77817
Change-Id: I10db56e93643722d1d6a85e66b9dd552ee654432
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
AnimatedImage already had these properties, but some typically non-animated
image formats such as PDF, TIFF and ICO can also support multiple pages.
In either case, the currentFrame property can be used to select a specific
frame or page. However an AnimatedImage uses a QMovie to do that, whereas
a plain Image uses QQuickPixmap. So the accessors need to be virtual in
order to have these different implementations.
[ChangeLog][QtQuick][Image] Image and BorderImage now have currentFrame
and frameCount properties which can be used to step through the frames of
multi-page image formats such as TIFF, WEBP and ICO.
Task-number: QTBUG-77506
Change-Id: Id4d95a99a26a862957e44b1bd8ffe06d7eababef
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Avoid that the last click from the previous test data and the first
click in the current test data happens so close in time that they are
interpreted as a double click.
Task-number: QTBUG-77389
Change-Id: Ia2d159452dcdb58cacccf7101cc3360175b39594
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
All tests compile and run on a developer build.
These tests are failing:
tst_qqmlsqldatabase Fails due to missing sql driver
tst_qqmlsqldatabase Fails in wip/qt6
tst_ququicklayouts Fails in wip/qt6
tst_flickableinterop Fails in wip/qt6
tst_qquickpinchandler Fails in wip/qt6
tst_qquickflickable Fails in wip/qt6
tst_qquickgridview Fails in wip/qt6
tst_qquickimage Fails due to missing jpeg plugin
tst_qquicklistview Fails in wip/qt6
tst_qquicktext Fails in wip/qt6
tst_qquickcanvasitem Fails in wip/qt6
tst_scenegraph Fails due to missing jpeg plugin
tst_TestFiltering Fails in wip/qt6
Change-Id: I4b9d69c118e23c095cb72ad5a67653fc30943bb1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This autotest is blacklisted as it is deemed flaky.
Task-number: QTBUG-77389
Change-Id: I3561c98f0248507755f99fd7b6fe24c3d24cb522
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The correct keyword set for blacklisting a test on mingw is
"windows gcc" not "win32 gcc".
Amends db8fc6e854
Change-Id: Idad4c9370b7d4c09acde160e6053191df7ee1aad
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
It's something to do with calling
QQuickText::setElideMode(QQuickText::ElideRight) not causing a width
change which the spy object expects to happen.
I don't know why it happens, but it's the last thing preventing me
from getting a working wip/qt6 branch, so I'm gonna blacklist the
test on MinGW.
Task-number: QTBUG-77394
Change-Id: Ia01e24f4e133c84ff44ce365595ad10292e845f9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Check that after we could not find an element, we do not suddenly find
one afterwards.
Moreover, disable the cacheBuffer as the asynchronous creation might
cause issues, leading to the flakyness observed in QTBUG-77330
Task-number: QTBUG-77330
Change-Id: I444eede16a99a75340a0b7ccf17193298730a675
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
An image inside at the end of a text block which did not start at text
position 0 would resolve to an invalid QTextLine, since we passed
the document position to lineForTextPosition(), which expects the
relative block position. If the image was aligned to top or
bottom, so that the extracted QTextLine was actually accessed,
this would cause a crash.
[ChangeLog][QtQuick][Text] Fixed a bug where aligning an image
to "top" or "bottom" could cause a crash under certain circumstances.
Task-number: QTBUG-77217
Change-Id: Iaa239ba482f2a765703656e4116cbebb8435a66e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Because centerOnScreen asks the window manager to move the window, but
does not wait for it.
This is applied in the same spirit as this change in qtquickcontrols2:
https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/268200
These tests appear slightly flaky on the Grafana dashboard, this commit
might help.
Change-Id: I30d3f4717aca435c94fb1a447c4b5c51021da3be
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
And show our users even more love.
This path element allows to specify a list of
polylines as a single list of lists of points.
[ChangeLog][QtQuick][Path] Added QQuickPathMultiLine.
Change-Id: Idf1d1dcd928bb19b9ad995322f86822448811537
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The view uses a visible items list, which is maintained by the refill()
method, to determine which items should be triggered to do the populate
transition. The refill() was only invoked when component completed
before doing the populate transition; but if the size of the view
depends on the size of window (for example, using anchors.fill), more
delegates could become visible after component completed. In such a
case, part of visible items were not be triggered to do the transition.
[ChangeLog][QtQuick][Item Views] Item views such as ListView now properly
populate delegates with a populate transition when the view is resized
after componentComplete.
Fixes: QTBUG-76487
Change-Id: Id90c3f73d9911c8a1d6d8b1ea0c51f6c27d0ed5b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
- Signedness of integer comparison
- Unused parameters and variables
- Ignored return values of QTest::qWaitForWindowExposed() (nodiscard)
- float to int conversions
Change-Id: Ibece620d3c980a5af3b7717486c841d8072ed8af
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Required a change to a #include; qquicksinglepointhandler.cpp was (at
least on Android) only seeing QQuickSinglePointHandler as a forward
declaration, so dereferencing it was a problem. The header that
defines it does #include the one it replaces here.
Change-Id: I6bc30ff9a91f55350172e4a4bcaaa7f99a2ffb28
Reverts what's left of e535109441
(amends 73258eca7a):
MultiPointHandler is not only for touch handling anymore.
DragHandler in particular needs to respect the acceptedButtons property.
Fixes: QTBUG-76875
Fixes: QTBUG-76582
Change-Id: I414e785dd09b297c93e5e9f162be23e4a44eca54
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
We don't want it to hold its position indefinitely after the button is
released. But in practice, reset() gets called again anyway in
QQuickSinglePointHandler::handlePointerEventImpl(), _after_
handleEventPoint(), which means after tapped() is emitted. Having the
point hold its position that much longer is convenient for applications
and more consistent with the state expressed by the release event.
Also amend the documentation.
Partially reverts 17237efaef
[ChangeLog][Event Handlers][Important Behavior Changes] TapHandler.point now
holds the release position while the tapped() signal is emitted.
Fixes: QTBUG-76871
Task-number: QTBUG-64847
Change-Id: I621a2eba4507a498788e9384344e8b4b7da32403
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
We already took care of cases when the handler is a child of the Item,
grab transitions involving Flickable etc.; but the bug is about a simpler
case when the handler is in the parent of the item that has the grab,
and steals from it. Amends 38a016c7b1
Fixes: QTBUG-71218
Fixes: QTBUG-75025
Change-Id: Id1d6d370e0db75c59ec7dce4a8e545701c501827
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QQuickState used to store "when" as a QQmlBinding to reduce state
oscillation.
It is unclear whether this is still an issue, but it breaks if a user
sets "when" to a primitive value like "true" or "1".
Fixes: QTBUG-76838
Change-Id: If400e5b1283687838ed252be2dfa52067f44564e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Setting the KeyNavigation.up property of an item to another item will
implicitly set the reverse (KeyNavigation.down) property on that other
item pointing back to the item. Once the item is destroyed, you will
have an invalid pointer stored in the other item pointing to the
destroyed item.
Using QPointer<> instead of raw pointers fixes that issue, because
they will become null on QObject's destruction.
Added QQuickItem test that verifies the issue is solved.
Fixes: QTBUG-75399
Change-Id: Ibb3e976c4eb9fcd81604bcc2eb757257d3653930
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The refill() method would bail out early on an empty model. Make sure
that it at least updates the header and footer in such situations.
Fixes: QTBUG-31677
Change-Id: I1f3a1848ff263a8f7f9ccfc3b20f16b61348f57b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
These tests have not failed on the removed platforms for at least 60 days
Task-number: QTBUG-76608
Change-Id: Ifad6dfed42ad5a832f50b705a0e9312413c0eb61
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
The cause was that fast flicking kicked items in and out of viewport,
while in transition, they would abruptly having tracking data structure
, i.e. releasePendingTransition of QQuickItemViewPrivate, got iterator
invalidated. This also helps to resolve QTBUG-44308.
Fixes: QTBUG-76433
Fixes: QTBUG-44308
Change-Id: If14533d3f6b1acd7b6ca0c5c723347c0cb3f54dc
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
So it can be used in QML. Useful in combination with ShapePath,
in order to add graphics along a Shape.
[ChangeLog][QtQuick][Shapes] Exposed QQuickPath::pointAtPercent
as invokable in QML.
Change-Id: Ia8aeb2b74003410ce16d9d2a0c62d79a021530af
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>
The wording of the warnings were changed in qtbase.
Fixes: QTBUG-76152
Change-Id: Iae0dfbcbb699b8abff92b5923b0a5627591043c8
Reviewed-by: Liang Qi <liang.qi@qt.io>
And show our users some love.
[ChangeLog][QtQuick][Path] Added QQuickPathPolyline.
Change-Id: I0fb78ae3e4e7c65e81e100595dc1eb16f88a68ed
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QGradient isn't meant to have a wide contract and filter out
garbage. Since we're parsing ints / strings as gradients, do
the validation at this level.
Change-Id: I271b5ed1b908d698a2d2c871abf5e61d1e565451
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
[ChangeLog][QtQuick][QQuickMouseArea] mouseX and mouseY will now
be synchronized after dragging the target item
Fixes: QTBUG-75993
Change-Id: I0b56f6bd494791f9e2fe55a0cf059a7bad2d63dc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
With this property, Paths and ShapePaths become scalable.
[ChangeLog][QQuick][Path] Added scale property to scale
a path before sending it in to PathView/Shape.
Change-Id: Id9ce7d1247d55e2cdb0d27a19c86fe0970e66268
Fixes: QTBUG-74456
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We need to respect QPlatformTheme::TouchDoubleTapDistance
Fixes: QTBUG-75770
Change-Id: I2adc7097bb29cb93beb2609a8a806a666856a0c8
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
But do not interfere with any custom cursor that user code sets:
remember and restore it when the mouse is no longer hovering a link.
Task-number: QTBUG-14769
Fixes: QTBUG-50482
Change-Id: Ia4633c22d0ad42d07203d4dc3e330b90a5f94a7c
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
There are now three mechanisms in TableView that works together to
ensure that the table ends up edge-to-edge with the content view. They
are applied in the following order:
1. Adjust the content size, based on the predicted size of the table.
2. Adjust the origin and endExtend on the fly, if the content size is wrong.
3. Move the table directly to where it should be, in case we don't have
time to wait for the origin to change.
We could have, strictly speaking, setteled with just one of them, but choose
to use them all at the same time for best flicking experience. Still, 1. and
2. sometimes step on each others feet when they both detect that something is
a bit off, and adjust.
So rather than adjusting the size of the content view every time we load a
new row or column, we just keep the first prediction. And then we leave all
later ajustments to 2. and 3. This turns out to be a more stable, and will
avoid some glitches that occur when flicking using a scrollbar, if several
mechanisms kick in at the same time.
Change-Id: Ib551a0bf8f6ee59ac9b3556b9462c91adb9cc80b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
This changes snap behavior slightly. Basically, it does not snap
anymore if the target() item is an ancestor of the parentItem().
In addition, we add a property that enables users to change the behavior.
(SnapIfPressedOutsideTarget has the old behavior)
[ChangeLog][QtQuick][Event Handlers] Added DragHandler.snapMode which can
be used to configure under which conditions the dragged item is snapped
to be below the cursor. The default mode is SnapAuto. The old behavior
can be obtained through the SnapIfPressedOutsideTarget mode.
Fixes: QTBUG-75661
Change-Id: Ibc00e8fbe31b779f8e817af1505e76425467d27a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We set the size of the content view to be the size of the complete
table. The problem is that the exact size will always be just
a prediction, since we would otherwise need to iterate over all rows
and column up front, to be able calculate the exact size.
This is not acceptable when using non-trival table models.
A side effect of this, is that is will be possible to flick the
viewport further out than the actual end of the table, if the
content view turns out to be larger than the table itself. From
before we used to just move the whole table back into the viewport
when that happened, which could be seen as a sudden jump of the
table to a new position.
This change will improve this logic so that we can avoid most
visual jumps. Instead of moving the table around, QQuickFlickable
supports moving the origin instead. So when we see that the
table is not in sync with the content view, we simple move the
origin to the edge of the table. The effect is that any flicking
or ongoing momentum animation in QQuickFlickable will continue as
if nothing happened. This is also the same logic used by QQuickListView.
Change-Id: I6060b7e84b9489c8fa569e6ff41b958e3871f8e7
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
When moving contentX/Y, we also need to ensure that the viewport rect
reflects the change. Otherwise we'll end up loading rows and columns
somewhere else then under the viewport.
Change-Id: Ifbd3d66b9b3a822414aefde9b5bd088274dfa2ad
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
We therefore need to keep track of which states have been explicitly set
or not in order to know which ones should get initialized with their
defaults.
Change-Id: I49fdae82288f04ea4f50d45735a93434ac02abec
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Test more of the text properties. This is still very incomplete, but a
small step forward.
Also make sure that editable text reports the editable state.
Fixes: QTBUG-75002
Change-Id: I9e43c980d8fa91671acb4e40e5d9162854884ee7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The model types are not part of the core QML runtime and should only be
loaded if you explicitly import them. We cannot enforce that in Qt5 as
some of them are available from the QtQml import, but we can change it
in Qt6.
Change-Id: I1e49e84d748e352537ec2d4af901c034c91d038f
Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
It can be used to change any qreal property of its target Item in
response to wheel rotation, or it can be used in other ways that involve
bindings but without a target item.
[ChangeLog][QtQuick][Event Handlers] Added WheelHandler, which handles
mouse wheel rotation by modifying arbitrary Item properties.
Fixes: QTBUG-68119
Change-Id: I247e2325ee993cc1b91a47fbd6c4ba0ffde7ad49
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Eskil Abrahamsen Blomfeldt
Qt Forward Merge Bot
Leander Beernaert
Wang Chuan
Ulf Hermann
Liang Qi
Eirik Aavitsland
Richard Moe Gustavsen
Shawn Rutledge
Fabian Kosmale
Mitch Curtis
Shin-ichi Okada
Jan Arve Sæther
Friedemann Kleint
Kari Hormi
Alexandru Croitor
Michael Brasser
Timur Kristóf
Simon Hausmann
Stephen D'Angelo
Teemu Holappa
Sona Kurazyan
Dimitrios Apostolou
Paolo Angelelli
Edward Welbourne
Laszlo Agocs
Tom Scheler
Daniel Smith
Yulong Bai
Giuseppe D'Angelo
Frederik Gladhorn