| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickPopup::~QQuickPopup hides its overlay in its destructor. If a
Behavior is installed on its opacity property, it will get triggered by
this. If the animation associated with the Behavior is a property of the
Popup, which is bound to a QML element, it will however be already partially
destructed, as QQmlElement<QQuickPopup>::~QQmlElement and in turn
QQmlPrivate::qdeclarativeelement_destructor will have deleted its
associated memory, before QQuickPopup::~QQuickPopup has been called.
As this does not set any pointers to null, it would seem as if the
Animation were still valid. To remedy this, we now check if the
animation is in fact marked for deletetion, and, if so, bypass the
interception.
Fixes: QTBUG-80070
Change-Id: I0e33262c6b3963c46e300ae76c05063c00ff258b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 991035ea1f00671d79c340a8a5c038e6aae1ece7)
Reviewed-by: Mitch Curtis <mitch.curtis@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 dcc7367997e7241918cdf0c702c7bb8325eb1ad4.
Fixes: QTBUG-76954
Change-Id: I836baf771f09d48be8d032472b0c3143e8f7f723
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 7cdc3727a2b01c59d0a9e19a3cfc4e226ac1ab77)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The infinite loop was triggered by several issues coincide together.
In short, the direct cause is the particle's born time and lifespan were
represented in 32 bit floats and not precise enough to pass aliveness check as
time grows large.
While the time grows large, the resolution of floating point decreases to the
extent that resolution is even bigger than 2 milliseconds.
Then it will fail to pass the aliveness check. Then, the
dead particles will be treated alive and they are kept inserting into and
popping out of the particles heap, which is similar to a live-lock.
The fix is to separate freeing dead and inserting back alive ones in two
different loops, ensure that the emitter can update time for next frame.
There are still other issues:
1) as the times runs very long, the particle needs several frames's updates
to actually make the states change noticeable, which means animation may
become not so smooth after running for too long (like several days).
May change particle's born/lifespan time to 64 bits in another patch.
2) the particle system's and animation's timers are 32 bit integers,
after 2^31 milliseconds(24.8551348 days), they will overflow. May promote
them to 64 bits in another patch.
3) as the time grows even larger such that the resolution is bigger than 16ms
at 60 hz frame rate, the live-lock may occur again. Because the timer advances/delta
will be not large enough to make dead ones reused.
The next live-lock estimated time is 2^24*16 milliseconds = 3.10689185 days.
The final fixes are 1) and 2)
4) may change the particle system's internal timer be set to arbitrary value
(fast forward to large value) for easier writing autotest for above cases.
Change-Id: I1190c0814c8197876b26dd4182dc4b065dd1ece6
Task-number: QTBUG-64138
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
(cherry picked from commit f8df9dc8b45cd9e386b66255183c58f3dfcc41a9)
Reviewed-by: Liang Qi <liang.qi@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>
(cherry picked from commit 23df1603f514407d245a2740f32f589318ef654e)
|
|
|
|
|
|
|
|
|
| |
This ensures that the QOpenGLContext has the right screen information
and can create a compatible context for use with QQuickWidget.
Change-Id: I9d78ff2b616e5c1d1c11d1da438ce336a0f24953
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 4080025fed9d43a78b578bcab67397712459d28c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
(cherry picked from commit 0012f8bd152a36a67abc696465f27d612625b5d9)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If isValueType() returns true, we should really return a non-null value
from valueType(). Otherwise the assumption that
QQmlValueTypeWrapper::valueType is never null breaks. In particular, the
unknown type and various primitive types are _not_ value types. We
special case the, probably common, UnknownType and check the actual
return value of valueType() for anything else. In order to avoid looking
up the metaobject each time we request a type that is not a value type,
we keep an invalid value type as marker for "not checked yet" and
replace that with nullptr once we determine that the type in question is
indeed not a value type.
Fixes: QTBUG-76866
Change-Id: I797f4cdd4db48ffc1b8fa2d919afc8022f67fa94
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
(cherry picked from commit f862b3edeb8a96a49a5d12620506d33d5a5aadca)
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
(cherry picked from commit ae346195efaca5d01b67c5df1209512c7edaddb0)
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
(cherry picked from commit 3df387d63421f09533ab72e2a73fb5d259693120)
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A side effect of 8fd398c9d2f5f54e446e0b402bc63a2edb50da6f 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 e2df4233a77ce8a37d2c8ef26b7b42fc0d33a24b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the rules already had Semicolon at the end, however it was
missing for UiScriptStatement, list properties and UiObjectInitializer.
This change fixes the regression from 5.11.3 to 5.12.0, and keeps the
behavior consistent.
(Semicolon was only introduced in 5.14, that why we need to introduce
the rule in 5.12 first)
Fixes: QTBUG-77954
Change-Id: I45ef35fab399e3f971444b96d4a9ec6a99e29e09
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 45b1a3f97953fac65c6aef8e46abad865a0d0bc3)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the filters list is the same as before, then there is no reason to
trigger an update on the thread as the result would be the same as
before. This solves a problem that was occurring with iOS 13 as it would
get stuck due to repeated calls to setNameFilters() with the same
filter list.
Fixes: QTBUG-78468
Change-Id: I705cfaaa0a1a19b1d0397140a5831fc67557a4ee
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit 9274ed77bc273330a3f202a00239dcc1b6ef8cc3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to keep the accumulator alive across function calls. This
requires:
1, Saving the accumulator on the stack if the function might allocate, to
protect it from the garbage collector. However, we don't need to do
that if the result of the function is to be saved in the accumulator
and the function itself doesn't use the accumulator as argument. In
this case the previous value becomes unaccessible and we might as
well GC it.
2, In the JIT, restoring the accumulator from the stack after the
function call if we want to ignore the return value.
3, Therefore, also saving the accumulator on the stack before calling in
case of 2.
We assume that we don't need to keep the accumulator alive across the
jump to the exception handler. Saving the accumulator more often than
necessary is detrimental for performance. To make sure the assumption
holds, explicitly load the accumulator with undefined _before_ jumping
to any exception handler.
Change-Id: I78cbc42847b8885a0659b23f3b81655b7f1a0bc4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
Change-Id: I243d12b75a07ac04560b444c326bff77d0dc642c
Fixes: QTBUG-74087
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
(cherry picked from commit 426f3035a3753800ce340a83bdf8db13922f4cae)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I1599dde865a7c5454a52b45b2cc877a8c43fb10d
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
| |
It was intended to inherit most of the docs from SinglePointHandler; but
the hovered property is unique.
Task-number: QTBUG-68072
Change-Id: I4b49569c9966b9252a61e40e8b07ef98f34849a4
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the missing lookup for cached .mjs files in
ExecutionEngine::compileModule. This allows using .mjs files in
WorkerScript {} elements in conjunction with the Qt Quick Compiler and
also fixes the use when using QJSEngine::importModule.
[ChangeLog][QtQml] Fix loading of EcmaScript modules when using the Qt
Quick Compiler.
Fixes: QTBUG-77761
Change-Id: I58130b0468f4920b2f6c49b98a2f51d5ae3a0491
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
It is generated and modified at runtime, so applications have to
synchronize access explicitly.
Fixes: QTBUG-70915
Change-Id: Ie6f29eef8532e2fa4ebf8dad1678cd2acbacf659
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-42798
Change-Id: If10f06450f1e50893e5ba103e7c8c2d83667a651
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@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>
|
|
|
|
|
|
| |
Fixes: QTBUG-73541
Change-Id: Icb15cee3c49f142ef3634e35427dbbc0b9a2183e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This would break importing older versions of a module, as we would try
to locate a singleton which does not exist in this version.
Fixes: QTBUG-77102
Change-Id: I78be1ec111d2be26a14b2a94bbf743cf6238cddd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-77094
Change-Id: I9058bf7b65e8d390327af0624df611de4965f1e4
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to support pen color for color fonts, we have to bake
the color into the cache (since the cache contains actual
color data and not alpha values).
This is equivalent of 78caba7ae637bf4b33631c3425eb92ec3946c99e in
Qt Base.
[ChangeLog][Text] Added support for text color when using color fonts.
Task-number: QTBUG-74761
Change-Id: I5910636c240bd4c0ec3f0b13db4e2f78d4b062ff
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-77094
Change-Id: Ia974c4d8abeab48a206fb868ee5532d4aeae7319
Reviewed-by: Mitch Curtis <mitch.curtis@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExecutionEngine::callingQmlContext() in some cases returns a null pointer.
According to ISO/IEC 14882 §9.3.1/1 "If a nonstatic member function of a
class X is called for an object that is not of type X, or of a type
derived from X, the behavior is undefined". Thus, invoking a
QQmlContextData::resolvedUrl() member function on a null instance results
in undefined behavior, and leads to a crash in some cases.
ExecutionEngine::qmlEngine() in some cases returns a null pointer. The
QQmlEnginePrivate::get() method must return a pointer to a QQmlEngine
private internal class. Call QQmlEnginePrivate::get() with passed null
pointer leads to application crash. If the QQmlEngine pointer is null,
the QQmlEnginePrivate pointer should also be null. Thus, if the pointer
to QQmlEngine is null pointer, the null pointer to the private class
should be passed to the QQmlEnginePrivate::warning().
Task-number: QTBUG-75983
Change-Id: Iad240bb6db0be58e9087b7a86f8d400b07623865
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
Use the GL attribute name helper functions only from QtQuick to avoid
a clash of symbols when linking statically.
Change-Id: Ic95b984092f5db222db6dc1f4ac5fb443b5ab714
Fixes: QTBUG-77012
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-71329
Change-Id: I261b25ff281bb44d03650ab05258743f104f3cc9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverts what's left of e53510944169ac9f6753e0d14e1b24a24ff7bd9a
(amends 73258eca7ab7e3981d9f4aaa5484020cb67854a0):
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 17237efaefabe924599abe00e92d8b54032d7915
[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 38a016c7b1337d83d77879f45b4a2e6fec11d049
Fixes: QTBUG-71218
Fixes: QTBUG-75025
Change-Id: Id1d6d370e0db75c59ec7dce4a8e545701c501827
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the way the area allocator is used, where one area spans
all the textures, it is possible to have the situation where part
of a glyph is allocated to a texture N and the rest to N+1, i.e.
the split happens inside the glyph. In a case like this, the
cache would grow the texture in question to accommodate the glyph,
which would in turn cause the height of the texture to be too
large.
For most systems, this would not happen, since a single texture would
be enough for a font, but when it does the texture creation may fail.
The fix is to reduce the height of the area allocated to each texture
by one row height, so that if the glyph does happen to hit the border
between two and the texture needs to extend, it will still not exceed
the actual maximum height.
[ChangeLog][Text] Fixed a bug when displaying many characters from the
same font on a system with a low maximum texture size.
Task-number: QTBUG-76528
Change-Id: I1e559aaf90552afe8531872264186daa5ee61939
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The allocated area for each texture has to have its origin at (0,0)
otherwise the actual required height of the cache is too low. When
using the texture upload workaround, this would crash, and when not
it would lead to missing glyphs.
Note that this is because the texture may contain a bit of empty
space at the top, since the area allocator may allocate this area
to a glyph which actually belongs to the previous texture (we use
a single area allocator for the entire cache and some glyphs may
overlap the limit between two textures).
[ChangeLog][Text] Fixed missing glyphs and in some cases crashes
when large character sets were being used on system with a low
maximum texture size.
Task-number: QTBUG-76528
Change-Id: I710ebbdd2feba4567505393fb12f89b5dd8501f1
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the path might get interpreted as some other part of the URL,
for example the host name.
Fixes: QTBUG-76441
Change-Id: I3edde96153403962db4576e5af794419c21b49a8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: I177ea278b5039688923fc23425a1377522412d08
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Avoid a crash when setData or create are
called after a user mistakenly used the internal constructor of
QQmlComponent which does not take an engine.
Fixes: QTBUG-55407
Change-Id: Ia4295d1b044723efce1a95607349561d4f1640da
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
| |
The allocation might run the garbage collector and that might delete the
object before we ref it.
Change-Id: I13cb74ab011a4eabc8df136023958791a2183df0
Reviewed-by: Simon Hausmann <simon.hausmann@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7cb6dce1f3e140ea68d6b05281950f212fc99d38 introduced an
optimization to remove bindings that after their initial evaluation had
no dependencies or errors (such as when accessing properties not set
yet). However when accessing a context property in a silent way -- using
typeof -- then no error state is set and the binding is removed. Any
later change of the context property results therefore in no binding
re-evaluation. This patch skips the optimization on bindings that are
associated with a context that has unresolved names. This fixes the
concrete bug at the expense of disabling further optimizations in the
context if other bindings access unresolved context properties. However
since context properties are discouraged anyway, this may be an
acceptable price to pay.
Change-Id: I95e120a4f71e8ebe0ec1fc44e8703c75f920dd28
Fixes: QTBUG-76796
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just like resolving the lookup initially, we need to set the base also
when hitting the cached lookup code path. The base is then used as this
object.
Fixes: QTBUG-76656
Change-Id: I6f6be05bc9875ddccc6e112e91176a0fa24a8fa1
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
At the point the plugin is actually unloaded the hook turns into a
dangling pointer.
Fixes: QTBUG-71387
Change-Id: Ib8ccee3f9a86d4700fbea7e87c666cd8f30f71e4
Reviewed-by: Simon Hausmann <simon.hausmann@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>
|
|
|
|
|
|
|
|
|
| |
`Q_INIT_RESOURCE` cannot be used from within a Qt namespace. so we
move the `Q_INIT_RESOURCE` call to static function defined on the global
namespace
Change-Id: I9eed7699e969369f861b95cdf3f7376ade73c1b3
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|
|
|
|
|
|
|
|
| |
We need to repaint everything on devicePixelRatio change,
like we do on size change.
Task-number: QTBUG-66810
Change-Id: I6b2c2ae92335a0aca731a4b0e7621cf7d08881e3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
If the size of the texture changes, but subrect stays the same, the
geometry changed and is now dirty.
Change-Id: I5a4de88fd3f788a686fb2186185da2a0a3faad82
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|