summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* threadedanimation: fix custom item animation when in a QQuickWidgetMitch Curtis2017-12-201-2/+5
| | | | | | | | | As with 64a01ff5b5d1eaadb1e60013673ac25459b79e14 in qtquickcontrols2, we ensure that custom scenegraph item animations still run if within a QQuickWidget. Change-Id: I3630ee34c039420640000c9a58ed1ec186bbe82c Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* Let platform decide what the default show action isTor Arne Vestbø2017-12-191-6/+1
| | | | | | | | | | | 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 test to QQuickShortcut when render window is usedKari Hautamäki2017-12-193-0/+181
| | | | | | | | | 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>
* QQuickItemView: Clear pending changes when refillingUlf Hermann2017-12-183-35/+163
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remap the coordinates in QInputMethodQueryEvent based on widgetWeng Xuetian2017-12-171-1/+32
| | | | | | | | | | 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>
* QQuickList/GridViewPrivate::fixupPosition: don't set moveReasonShawn Rutledge2017-12-163-5/+14
| | | | | | | | | | | | | | | 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>
* Add new logging category qt.quick.window.transientShawn Rutledge2017-12-156-3/+58
| | | | | | | | | | | | | 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>
* Fix QSGTexture* leak in QQuickFramebufferObjectLaszlo Agocs2017-12-141-0/+1
| | | | | | | | | | | 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>
* Fix stack use after scope when calling overloaded constructorsSimon Hausmann2017-12-141-1/+1
| | | | | | | | | | | | 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>
* remove unimplemented QQuickItemPrivate::_q_windowChanged declarationShawn Rutledge2017-12-131-1/+0
| | | | | | | | It was added in 4c5445ddb0e7388247783c868925c086bdd666f7 but never implemented. Change-Id: I748295b2a1d82ed19444c0e447e1d7e88baf34b1 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Flickable: don't jump after premature movementEnding due to timerShawn Rutledge2017-12-131-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Bump versionOswald Buddenhagen2017-12-121-1/+1
| | | | Change-Id: I83db540f23f7c11414b17720e8180f496f6c45a4
* Add the source directory as import paths in tst_qqmlimportUlf Hermann2017-12-111-3/+3
| | | | | | | | 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>
* Pass the source directory in the plugindump testUlf Hermann2017-12-112-1/+2
| | | | | | | | On shadow builds this fails when just passing ".", because "." is the build directory. Change-Id: Iee84b73f2c4e5c8663d84d53b31f658501244dc9 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Handle the application state changes so items update appropriatelyAndy Shaw2017-12-112-2/+10
| | | | | | | | | | | | 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>
* Fix valgrind warning about uninitialized variableLars Knoll2017-12-111-1/+3
| | | | | | | | 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>
* Make deletion of transitions safeLars Knoll2017-12-113-23/+39
| | | | | | Task-number: QTBUG-63844 Change-Id: I65029e9039ea3db85152fc3cdefaac3deee0db6c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Add logging categories for GC statisticsLars Knoll2017-12-113-101/+70
| | | | | | | | | | | 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>
* QQuickWidget: preserve QMouseEvent::source when mapping to the QQ windowShawn Rutledge2017-12-061-7/+10
| | | | | | | | | | 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>
* qtquicktest: remove dead INSTALLS from qmltest.proGatis Paeglis2017-12-061-6/+0
| | | | | | | | | | 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>
* grabMouse() and QQWPriv::removeGrabber(): be clear whether mouse or touchShawn Rutledge2017-12-055-41/+137
| | | | | | | | | | | | | | | | | | | | | | | 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>
* D3D12: Fix compilation with clang-clFriedemann Kleint2017-12-051-1/+1
| | | | | | | | | 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>
* Restore a temporary QQmlInstanceModel::object() overloadJ-P Nurmi2017-12-011-0/+1
| | | | | | | | 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>
* Add a means to unregister custom qml typesAndy Shaw2017-12-015-0/+232
| | | | | | | | | | | | | | | 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>
* QQuickListView/GridView: load items that results from model changes ↵Richard Moe Gustavsen2017-11-304-4/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QQmlDelegateModel: add incubationStatus(), and use it to determine ↵Richard Moe Gustavsen2017-11-306-3/+38
| | | | | | | | | | | | | | '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>
* QQmlIntanceModel: use QQmlIncubator::IncubationMode instead of bool to ↵Richard Moe Gustavsen2017-11-3013-43/+46
| | | | | | | | | | | | | | | | | | | | | | 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>
* don't get confused about the grabber during replayDelayedPressShawn Rutledge2017-11-292-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Check linked contexts for context objects being deletedUlf Hermann2017-11-281-1/+4
| | | | | | | | | | 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>
* Fix crash when moving items during asynchronous creationJoni Poikelin2017-11-283-2/+85
| | | | | | | | | | | | | | | 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>
* Merge "Merge remote-tracking branch 'origin/5.9.3' into 5.9" into ↵Liang Qi2017-11-254-5/+89
|\ | | | | | | refs/staging/5.9
| * Merge remote-tracking branch 'origin/5.9.3' into 5.9Liang Qi2017-11-234-5/+89
| |\ | | | | | | | | | Change-Id: Ic6457df47bed359fd43653e73726f1896944241c
| | * Fix crash when accessing pixmap on default QSGSoftwareInternalImageNodev5.9.3Allan Sandfeld Jensen2017-11-171-4/+5
| | | | | | | | | | | | | | | | | | | | | Task-number: QTBUG-64562 Change-Id: I52e07b0d8b7a5d1cc960431dcbd1a90dd3e7e518 Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
| | * Fix crash with dangling context object pointersAndy Shaw2017-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * Blacklist tst_qquickwidget::enterLeave() on MacJ-P Nurmi2017-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | Task-number: QTBUG-64397 (cherry picked from commit 5f16aa795d39969d93b520861a1e86729c7db90e) Change-Id: I28268ea87b81dd1f7dbf8bb5a8eb421962cc5f31 Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
| | * Add changes file for Qt 5.9.3Jani Heikkinen2017-11-121-0/+73
| | | | | | | | | | | | | | | | | | | | | Task-number: QTBUG-64181 Change-Id: I85a6150e00143b379143c353a37e844cb9708627 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
| | * Improve encapsulation of the the IR de-serialization from QtQuick CompilerSimon Hausmann2017-11-121-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | More fine-grained deferred property executionJ-P Nurmi2017-11-255-13/+265
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | QmlInspector: Make window flags explicit when adding WindowStaysOnTopUlf Hermann2017-11-241-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Re-enable QML memory profilingUlf Hermann2017-11-238-21/+84
| | | | | | | | | | | | | | | | | | Task-number: QTBUG-64674 Change-Id: I48ed1a51f66ef8d55cc026f140d270baaca04fbf Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | | Software Adaptation: Fix cliping logic error with empty clip regionsAndy Nichols2017-11-231-2/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | watch for the actual render window if there is a QQuickRenderControlMarco Martin2017-11-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Don't reject plugin-only qmldir filesUlf Hermann2017-11-223-14/+43
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix URL interception for qmldir filesUlf Hermann2017-11-226-17/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Document QQuickGrabGestureEventShawn Rutledge2017-11-172-1/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Make sure we remove stopped animators from the list of rootsGunnar Sletta2017-11-101-1/+3
| | | | | | | | | | Change-Id: I89b36ee7d03ac6b8d07b24c656d3311728e8f9c3 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* | Blacklist tst_qquickwidget::enterLeave() on MacJ-P Nurmi2017-11-091-0/+2
| | | | | | | | | | | | Task-number: QTBUG-64397 Change-Id: I28268ea87b81dd1f7dbf8bb5a8eb421962cc5f31 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Make tst_qquickframebufferobject pass on macOSJ-P Nurmi2017-11-091-2/+4
| | | | | | | | | | | | | | | | | | 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>
* | Fix tests/auto/quick/quick.proJ-P Nurmi2017-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix tst_qquickshadereffectJ-P Nurmi2017-11-092-5/+5
| | | | | | | | | | | | | | | | | | 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>