| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The platform handles this through the ShowIsMaximized and
ShowIsFullScreen platform integration style-hints, as well
as QPlatformIntegration::defaultWindowState(), which was
added specifically so that we wouldn't have to hard-code
the behavior in user code.
Change-Id: Ic019ccc2edd871a78bf94fd5fe572b9659416582
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
| |
Add auto test for shortcuts when render window is used to
draw QQuickShortcut.
Task-number: QTBUG-64548
Change-Id: If2eb1f5618ae5f21477cc239acb42bc73ca7ec99
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generally the bufferedChanges are an "extension" of the currentChanges,
which can just not be applied at the moment because we are in a layout
phase. If we regenerate or clear the whole view in the mean time, the
bufferedChanges become just as invalid as the currentChanges.
On top of that, refilling can trigger further changes, part of which
will be applied during the refilling. As that leaves us in an
inconsistent state, we need to loop the refilling until no further
changes are generated. As the changes might affect items that are
already visible, and therefore not subject to refilling, we need to
clear all the items before refilling in this case.
In QTBUG-46488 things are added in the onCompleted callback of the
delegates (by expanding the tree view, which translates into adding
rows to the list view). Depending on where you add the new items, the
list view might pick them up when iterating the model on refill() or
it might create delegates for the same model entry twice. So, if that
happens we need to discard the result and refill again.
Task-number: QTBUG-46488
Change-Id: Ie4e0a731f7feda6aa962b6cb9a6cd5c3bf90486e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Right now, we only obtain the coordinates from QQuickItem directly, it
uses different QTransform to map to the global. The point and rect value
need to be fixed to use the QQuickWidget coordinates system.
Change-Id: Ia16a1a80f58c4c3bef1575a568f7e359bdaebef3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In QQuickItemViewPrivate::applyModelChanges(), if
moveReason = QQuickItemViewPrivate::Other,
then QQuickItemView::trackedPositionChanged() will fail to call
d->setPosition(pos), which is normally what keeps the Flickable moving
for a while. Leave the reason as-is (it will be SetIndex in this
case), so as not to forget that we were actually trying to move down
when the sequence window->polishItems() -> QQIV::updatePolish() ->
layout() -> fixupPosition() did its part of the work of moving down.
Task-number: QTBUG-62864
Change-Id: I1021e2ea39265de9e1285e2ee17c5733189ab939
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to monitor the increasing number of places from which the transient
parent relationship can be detected; and a debug operator for
QQuickWindow so that these log messages are more useful.
[ChangeLog][QtQuick][QQuickWindow] added logging category
qt.quick.window.transient to check detection of transient windows
declared inside other Items and Windows
Change-Id: Ic899af648765fcdc59b8da7dd1f1bed20db300f2
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Ownership is not taken by the node. The dtor already destroys the
QSGTexture correctly so follow suit when recreating the FBO due to
a resize.
Task-number: QTBUG-65156
Change-Id: I13a9f0332bf75a4c624ea7dd24633625ca07c8d4
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a regression of commit 0d7dd44d781a73c4bd065c0660d4a2f824a86f05
that ended up moving the stack-local storage into a scope that's too
close. Pointers into the storage are stored in methodArgTypes and used
throughput the surrounding while loop.
Covered by tst_QJSEngine::newQMetaObject when run with ASAN.
Change-Id: I44928d67ebdb0b5bdcf99ddd8193f692c2a94539
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
| |
It was added in 4c5445ddb0e7388247783c868925c086bdd666f7 but never
implemented.
Change-Id: I748295b2a1d82ed19444c0e447e1d7e88baf34b1
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to ef8c6f6a0bf5e4c9ee41306f2df59048ab96038f: we emit
movementEnding for the benefit of the user, scrollbars, decorators
etc. in case the ScrollEnd phase means that movement really ended
(it means the user lifted his fingers from the trackpad,
but momentum events can cause the movement to continue after that).
But in case movement didn't end, we don't want to have a jump when
it resumes. But scrollingPhase will be true after an event with
ScrollBegin phase, and false after an event with ScrollEnd,
also false if the mouse is an ordinary wheel mouse without phases.
So when the timer fires, if the user has not yet lifted his fingers,
scrollingPhase is true, and that means scrolling isn't really ending,
so we should not set vMoved to false.
Setting vMoved to false will cause the drag() function to
reset vData.dragStartOffset to the current dy value, which
ultimately causes the jump in contentY. It should be done only
when scrolling really ends. If the timer fires and scrollingPhase
is false, we can be sure it really ended. But if you flick, then
rest your fingers, then lift them, there is no momentum, so the
final event has scroll phase ScrollEnd, and we need to run the
timer one more time to detect that there are no more updates
and finish the transition back to the default state (set vMoved back
to false, emit signals such as movementEnded, etc.)
The ultimate solution is to add another Qt::ScrollPhase enum,
such as ScrollMomentum, but we should not do that in the 5.9 series.
Task-number: QTBUG-63026
Change-Id: I854c52a680028cb1d43b133be65653d87a05a0b1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
| |
Change-Id: I83db540f23f7c11414b17720e8180f496f6c45a4
|
|
|
|
|
|
|
|
| |
On shadow builds the QML components won't be found in the build
directory.
Change-Id: I0f524063537669f68e64fc6c04a6756ed1d130fd
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
On shadow builds this fails when just passing ".", because "." is the
build directory.
Change-Id: Iee84b73f2c4e5c8663d84d53b31f658501244dc9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the application state is no longer active, then the items should be
acting as if the window deactivated in this case. This allows MouseAreas
for instance to ungrab the mouse when the application goes into the
background on mobile devices.
Task-number: QTBUG-53036
Change-Id: I5c9a56a5fd3ad3a2ef03ff114561c671874a9391
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
| |
The flaky qmltest autotest triggered these warnings quite a bit,
so maybe this helps stabilize that autotest.
Change-Id: Ib03a9fbbbde376296e7bea4cbd4ba2422907fe44
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-63844
Change-Id: I65029e9039ea3db85152fc3cdefaac3deee0db6c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
And use them to dump some useful information. This replaces
the old QV4_MM_STATS environment variable and introduces
the qt.qml.gc.statistics (for some stats at app exit) and
qt.qml.gc.allocatorStats (for stats on each GC run) logging
categories.
Change-Id: I0a16b25b8663aa7dbfe2adae299d3d990e8e5554
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
If the mouse event was synthesized by the operating system or Qt,
on a touchscreen, we don't want to lose this information before it
gets to Qt Quick.
Task-number: QTBUG-64241
Change-Id: Ia7b5eeeae9fe355bedfeb15001a9236e077b152c
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The path "$$PWD/features/qmltestcase.prf" existed when Qt Quick Test
lived in its own repository - "qtest-qml". About 7 years ago this
repository was integrated in Qt5, and qmltestcase.prf was moved under
qtbase/mkspecs/features.
Change-Id: I581a40b93e2b45c189fe5584b1a117b3d5b6fe95
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug was that a MouseArea could be stuck in pressed state if a touch tap
occurred simultaneously on a second MouseArea while the first was held
pressed by the actual mouse.
QQuickWindowPrivate::setMouseGrabber(QQuickItem *) had too little
information to make the right choice in case the given item argument is
null. It should not mean ungrab everything: in this use case, the mouse and
the touchpoint can be pressing two different MouseAreas, and releasing
either one should ungrab only the MouseArea that is being released.
However the only place it was called with nullptr was in removeGrabber(),
and in that context we are given all the information: which item to ungrab
and whether we want to ungrab mouse, touch or both. It's better to have
a little code duplication between QQuickItem::grabMouse() and
QQuickWindowPrivate::removeGrabber() than to lose this information
about which device(s) and Item to ungrab.
Task-number: QTBUG-64249
Change-Id: I0710534a05f3ceeb66105a03ab0f32a61df8a522
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
Fix error:
qsgd3d12engine.cpp(3049,48): error: qualified reference to 'ActiveTexture' is a constructor name rather than a type in this context
TransientFrameData::ActiveTexture::ActiveTexture(TransientFrameData::ActiveTexture::TypeRenderTarget, id);
Change-Id: I159be55bbfe6effe6f70bf5113d6a090add69463
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
| |
The API change in 60d589c broke Qt3D build. Restore a temporary
overload to unblock the CI.
Change-Id: I4debce4dc4ec7668b75854da3dc7e1813c9c34c5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cases where Qt is used in a plugin it is possible that a plugin will
be unloaded while Qt itself is still loaded and as a result there is a
chance that there will be conflicting types registered.
Therefore, to ensure that plugins correctly clean up after themselves
cleanly, we need to add a means to unregister qml types. This is
intended to only be used when the user knows what they are doing.
Task-number: QTBUG-56521
Task-number: QTBUG-56532
Change-Id: Ie396e522385004e6e9f3841e04f8072ff29cb15b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
synchronously
The current implementation created new items with default incubation mode, which
is AsynchronousIfNested. But from reading the code, it seems like changes to the
model were really expected to be handled synchronously, since there aren't any
sections in the code that will recover from situations were requested items ends
up incubating async. This is also backed by the fact that the second argument
used to be a bool set to 'synchronous'. The fact that this was translated to
AsynchronousIfNested later down the chain didn't seems to be taken into account.
A bug with this is found in ListView when it's embedded inside an async Loader.
In that case, all list items will be incubating async at startup, which is normally
expected and fine. But if the model assigned to the ListView is modified before the
loader has finished, async loading will also happen to the items created because of
the change. And then the situation described above will occur.
This patch will force any items loaded because of a model change to be synchronous.
This seems to be in line with the synchronous logic that already exists. And its
also quite acceptable, since changing the model before everything is completed is
a corner case, and can naturally lead to some stuttering in the list view anyway.
A potential for improvement on this logic is to try to recover whenever creating an
item fails. But this takes a lot of work because of the way model changes are
structured and stored, and can easily cause regressions. Since this is a corner
case, it is probably not worth it.
[ChangeLog][QtQml][ListView] Fixed a bug in ListView that sometimes make items
end up with wrong geometry when changes to its model happens while the ListView
is being loaded async (e.g if wrapped inside an async Loader).
Task-number: QTBUG-61537
Change-Id: I8d6857beaf8ef98b02bb46282a1312749b0fb801
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'requestedIndex'
We used to assign the currently incubating item to 'requestedIndex' based
on requested incubation mode alone. This is not sufficient, as the item
can also be loaded async when the mode is AsyncIfNested. To check if the
item is really loading async (and that we're not getting nullptr because
of some other failure), we need to ask the incubator.
Task-number: QTBUG-61537
Change-Id: Id1f458db4a7584a6b58d5bad0e7832ce4fc341dc
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specify incubation mode
The current implementation would pass a boolean to signal if asynchronous
or synchronous incubation should be used to create an item. The problem with this approach
is that passing 'synchronous" would translate to QQmlIncubation::AsynchronousIfNested
later down the chain. This meant that even if the caller requested synchronous incubation, it
could end up with asynchronous incubation anyway, e.g if an async parent incubator was active at
the time of the call. And this can easily come as an unhandled supprise for the caller, and as
such, cause unforseen bugs.
This patch is a first of a set of patches that is done to fix the bug reported in the task below.
It will not change any behavior, it is written to preserve the logic exactly as it were, just
as a preparation for subsequent patches. It makes it explicit at the call location what
incubation mode will be used, and especially make it clear whenever the AsynchronousIfNested
flag is in play.
Task-number: QTBUG-61537
Change-Id: I8b3ba5438ebb2cd59983a098bd8ceeeb844da87b
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a ListView with pressDelay contains a MouseArea in a delegate, and
you tap the MouseArea on a touchscreen,
QQuickFlickablePrivate::replayDelayedPress() sends a saved copy of the
original QMouseEvent, and then a synthetic release, without marking it
as synthetic. (QQuickFlickable is not touch-aware in any way: it
thinks the mouse events it receives are real ones.) As a result of
sending the delayed press through, QQuickWindowPrivate::setMouseGrabber()
is called and sets the touchpoint's grabber to the MouseArea, but
does not set the core pointer's eventpoint's grabber.
Flickable then ungrabs for itself, so we have to ensure that the
ungrab affects either the actual mouse or the synth-mouse, whichever
was in use. Then because the synthetic release is not known to come
from a touchscreen, QQuickWindowPrivate::deliverMouseEvent() was
checking the core pointer's grabber and concluding that there is no
grabber. In such a case, it now checks whether touchMouseId is set,
meaning that we are somewhere between sending a synthesized press and
release, gets the touchpoint's grabber (which is MouseArea, because it
didn't reject the press), and sends the release there.
Task-number: QTBUG-61144
Change-Id: I494873e48af179bc63b618e881ba469b97dadf4d
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
In QQmlObjectCreator::createInstance we can assign the new object as
context object to a linkedContext of its QQmlData, not only it's
ownContext. Consequently, we have to check all the linked contexts
and remove the object when found on deletion.
Change-Id: I09bccdb0190406245fa5a379edaff0a8f118062f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In complicated cases where the model moves rows around while
the view is running slow (perhaps during high CPU load),
there were cases when Repeater would call
movedItem->stackBefore(deleteableItem), but deleteable items
can be null, so there was often an error
QQuickItem::stackBefore: Cannot stack before 0x0, which must be a sibling
and occasionally a crash. Now we check both the callee and the
parameter to stackBefore to make sure neither of them are null.
Task-number: QTBUG-54859
Change-Id: I45a8b2939c16b9bbe3a802ddd348dc55f51061a7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|\
| |
| |
| | |
refs/staging/5.9
|
| |\
| | |
| | |
| | | |
Change-Id: Ic6457df47bed359fd43653e73726f1896944241c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Task-number: QTBUG-64562
Change-Id: I52e07b0d8b7a5d1cc960431dcbd1a90dd3e7e518
Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a regression introduced by commit
e22b624d9ab1f36021adb9cdbfa9b37054282bb8, where the object that owns the
QML context would destroy the context upon destruction. Now the context
may live longer and thus the context->contextObject pointer would become
a dangling pointer.
Task-number: QTBUG-64166
Change-Id: I1df631fa11187abdeff735d8891ad7907e8d4a3d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Task-number: QTBUG-64397
(cherry picked from commit 5f16aa795d39969d93b520861a1e86729c7db90e)
Change-Id: I28268ea87b81dd1f7dbf8bb5a8eb421962cc5f31
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Task-number: QTBUG-64181
Change-Id: I85a6150e00143b379143c353a37e844cb9708627
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The code used by QQC to deserialize the IR requires setting the
javaScriptCompilationUnit member in order to connect the generated C++
code. Knowledge of the QmlIR::Document data structure layout on the side
of the generated code (thus application) has its downsides though (see
referenced bug). We can avoid that dependency easily by doing the entire
de-serialization on the QtQml library side.
The old "API" (load member function) is still around until the qqc
change is also in.
Task-number: QTBUG-63474
Change-Id: I239838afacc71474c86114b5b05679ff36e4c2e2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This allows Qt Quick Controls 2 to defer the execution of certain
building blocks until needed. For example, a button control can
defer its background item so that the default background is not
executed at all when replaced by a custom background.
First of all, this gives a massive performance boost for customized
controls. Secondly, this avoids the most burning issue in QQC2,
problems with asynchronous incubation ("Object destroyed during
incubation").
Task-number: QTBUG-50992
Change-Id: If3616c9dac70e3a474a20070ad0452874d267164
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The implicitly assumed flags are removed if any explicit flag beyond
Window, Dialog, or Tool is added. Thus the inspected window lost its
decoration when it was WindowStaysOnTop was set.
Change-Id: Ic155283fd17ed069790875679b150f2c37b7fe1a
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Task-number: QTBUG-64674
Change-Id: I48ed1a51f66ef8d55cc026f140d270baaca04fbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous fix for nested clip regions introduced a regression which
broke nested clipping cases that involved one of the clip nodes being
null regions because they were offscreen.
The clip region stack can either have an null QRegion or be empty as an
initial state (depends on what is being rendered). We made a special
check for these two states, but it is not enough to check if the top
item is null for the null region case beacuse at any point in time a
null clip region node could have been added. So to fix this the null
initial state also requires a count of 1.
Task-number: QTBUG-63743
Change-Id: Ib0d17026f1d5a663e819412e11d25d9ad8b445ff
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
if the scene is rendered by a QQuickRenderControl and we have a different
target window (for instance QQuickWidget) we check the target window of
the render control instead of the own window, this fixes window keyboard
shortcuts for QQuickWidget
Task-number: QTBUG-64548
Change-Id: I7614be580f2a707c752189e4c9b53a5d5f0159d7
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On QQmlImportsPrivate::updateQmldirContent we need to check if the new
module has actually been established after figuring out that it doesn't
have any components or scripts. If it has, then we shouldn't fail, as
obviously a plugin has been loaded. We don't need to check the component
and script versions in that case, as plugins don't have separate
versions.
Change-Id: Ie328b59038fe65c3f6a2eeecfe969927bba6cd68
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We need to intercept the URL when it is created. This relieves us of the
need to hack around in it when actually retrieving the content of the
qmldir file and prevents the futile attempt to load remote qmldir files
via the code path that should load local ones (or vice versa).
The back and forth conversion between URLs and strings is unfortunate,
but can only be solved by using QUrl rather than QString where we
actually mean URL. This would be a bigger change which is unsuitable for
5.9. Mind that nothing changes for code that doesn't use URL
interceptors.
Task-number: QTBUG-36773
Change-Id: I6bff3ae352009fdc0a17ec209691c7b390367f11
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Documentation has been missing since the beginning.
Making it an uncreatable type provides the opportunity to associate
the C++ type with the QML type so that the latter can be used in the
QML documentation, as opposed to simply registering the C++ type
with no QML name as was done before.
Task-number: QTBUG-47290
Task-number: QTBUG-63143
Change-Id: Ib82cc7b27c9591eaf2c7997d2781a2b4246cfbff
Reviewed-by: Michael Brasser <michael.brasser@live.com>
|
| |
| |
| |
| |
| | |
Change-Id: I89b36ee7d03ac6b8d07b24c656d3311728e8f9c3
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-64397
Change-Id: I28268ea87b81dd1f7dbf8bb5a8eb421962cc5f31
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The test has not been run in the CI, so the problem went unnoticed for
a long time.
Change-Id: I42a44a5fb89c0bd78e8997d4841e85672c73acdb
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following auto tests have not been run in the CI at all:
- tst_qquickanimatedsprite
- tst_qquickframebufferobject
- tst_qquickopenglinfo
- tst_qquickspritesequence
- tst_qquickshadereffect
Change-Id: Iacc832563fd2c002eef480fa4d42469d852adc0f
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The expected signal counts were not matching. Since the test has not
been run in the CI, it went unnoticed. Furthermore, the test crashed
due to a missing null pointer check.
Change-Id: Iff80a2ea17832eb7bc531ac9eb2fc482f2c69e38
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's such a common mistake to observe that they normally go to zero at
the top-left corner, but fail to realize that they won't always do that.
Task-number: QTBUG-64219
Task-number: QTBUG-22894
Task-number: QTBUG-27884
Change-Id: I6bc81d4761debdaff8fb3366bf1e944241207157
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|