Commit message (Collapse)AuthorAgeFilesLines
* Update dependencies on '6.0.0' in qt/qtdeclarativeQt Submodule Update Bot2020-11-241-2/+2
| | | | | Change-Id: I627754227cda376eea1bafedcdd163094941725a Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* Update dependencies on '6.0.0' in qt/qtdeclarativeQt Submodule Update Bot2020-11-231-2/+2
| | | | | Change-Id: I497c80c19d6bc9aba7876132ed0ef20aec632810 Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* Clean up and un-blacklist tst_QQuickMouseArea testsShawn Rutledge2020-11-202-436/+251
| | | | | | | | | | | | | | | | - Use QQuickTest::showView() consistently to reduce boilerplate - Use QTest::mouse*() where possible rather than constructing QMouseEvents (and potentially getting them wrong) - Use QPointingDevicePrivate::firstPointExclusiveGrabber() on a specific device to check grab state rather than QQWindow::mouseGrabberItem() - The warning "event went missing during delivery!" has been removed, so tst_QQuickMouseArea::nestedEventDelivery() shouldn't expect it Task-number: QTBUG-86729 Change-Id: Ieb1af38c118dadf8cdf8ae19f92002207d71d5b5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit f1a9c9b4273ec6104a0543b5cf48281141f613e6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-201-2/+2
| | | | | Change-Id: Ib40299337a3f0eabc0c87e871242558520f91dda Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-191-2/+2
| | | | | Change-Id: Ie0f6533c6f5458aedf78a7191b4044eb3a9823d7 Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* Make sure we don't modify the incoming event objects when localizingVolker Hilsheimer2020-11-192-4/+9
| | | | | | | | | | | Restore the position of the single event point after event delivery. Where possible, don't make a localized copy which explicitly shares its data with the original anyway. Instead, access the original directly. Change-Id: I5efa44c336eddeef1a1ab00dc91e2d0f223ed31d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix tst_QQuickMouseArea::notPressedAfterStolenGrab againShawn Rutledge2020-11-195-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem() doesn't need to call item->mouseUngrabEvent() because all grab changes are notified via the connection from signal QPointingDevice::grabChanged to slot QQuickWindowPrivate::onGrabChanged(). But in this case, MouseArea only accepts the event, rather than taking the grab itself. Therefore at the time the grab is "stolen", there was not yet any grabber, because grabbing is done after delivery. But we still need to inform MouseArea that it's not getting the grab it expects to get, so that it can reset its pressed state. But we don't want it to be redundant (other tests are counting events, and we don't want repeated ungrabs to show up in those); so now we have to track whether the item on which we're about to call mouseUngrabEvent() has already gotten it. This illustrates another problem with the tradition of accepting events and being unclear about what it means. Grabbing is one thing, ending delivery is another. Amends a97759a336c597327cb82eebc9f45c793aec32c9 Task-number: QTBUG-55325 Task-number: QTBUG-86729 Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickItem::windowDeactivateEvent(); cancel grabs insteadShawn Rutledge2020-11-196-22/+38
| | | | | | | | | | | | | | | | | | | When a QQuickWindow is deactivated, visiting every item in the entire scene to tell them the news isn't very efficient, especially considering that the only item that overrode this virtual function has been QQMouseArea, throughout the lifetime of Qt 5. If it's important to cancel grabs of MouseAreas, then it's equally important to cancel grabs of MultiPointTouchArea, pointer handlers, etc. It should be OK to delete the virtual function since it was never documented, and marked \internal, so hopefully no users are depending on it. The existing tst_QQuickMouseArea::pressedCanceledOnWindowDeactivate() test continues to pass, which proves that the WindowDeactivate event still has the desired effect on MouseArea. Change-Id: I0109370aba14096fb7777a83cf1b6763ac58013f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QMutableSinglePointEvent's new default constructorVolker Hilsheimer2020-11-191-6/+6
| | | | | Change-Id: I3b2d1fbc4b62b501aa6ed748a692cb4bba261c5e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add Qt 6 Qt Quick QML Type changes from qtdocJerome Pasion2020-11-191-1/+99
| | | | | | | | | -changes to Qt Quick QML Types and OpenGL support -content from doc/src/qmlapp/applicationdevelopers.qdoc Task-number: QTBUG-87156 Change-Id: I3384e5bfa070c891015e5aa4af2e2c0b2dae35cf Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Conditionally disable tests that depend on cxx11_future flagTony Sarajärvi2020-11-191-0/+2
| | | | | | | Task-number: QTBUG-88650 Change-Id: I2cac1b8ca7ec8ed8401206cf761244b3f483ca14 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-191-2/+2
| | | | | Change-Id: I1250aec61bac08e4b658ae24a51fab5d54576c14 Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* Porting guide: mention qmlDebug/Info/WarningFabian Kosmale2020-11-191-3/+3
| | | | | | | | Also don't mention qmlExecuteDeferred: That one is internal anyway (albeit not explicitly marked as such yet). Change-Id: Icef5fb4092b6a109613ae1f2e90fcff93d7c0b4b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QtQml: document qmlExecuteDeferred as internalFabian Kosmale2020-11-191-0/+3
| | | | | Change-Id: If3640ef5cbb6df4b199b481410e79e94ea763645 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Remove compatibility shim from qmlinfo.{cpp|h}Ulf Hermann2020-11-193-53/+19
| | | | | | | | | | | | We don't need to handle symbol clashes with QtQuick1 anymore. [ChangeLog][QtQml] The functions qmlDebug, qmlInfo, and qmlWarning are no longer available in the QtQml namespace. Use their counterparts in the global namespace. Fixes: QTBUG-88637 Change-Id: Ia74510bd711790cebf55de4cd668891712f6835e Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Stop ungrabbing due to FocusAboutToChangeShawn Rutledge2020-11-182-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to un-blacklist the test for QTBUG-60123. To that end: revert 7b2e2117162594a2d0234bb02408f5b5a446488b and its followup 6933b7e8e6dc279a8eb34e1f4c60bc109dfb7d26. There is no detailed bug report explaining exactly why those were done, just the comment on code review: "This fixes the desktop components' combo box on linux re-opening at random times", probably referring to a combobox popup window in Controls 1. But when using QWidget::createWindowContainer() in two different windows and clicking MouseAreas in each of them, it turns out that this change of focus is causing the mouse grab to be canceled. The grab should be naturally given up after mouse release; canceling prematurely doesn't make sense. The Qt 5 fix for this bug was e0c30279ec1fad88346ed3fb483bc3c672fdd01b which tracked the grab on a per-window basis. It would be difficult to do that again now (change QPointingDevicePrivate::setExclusiveGrabber() to store a separate grabber for each window in which a grab occurred? what could go wrong...) It seems odd to have the same QEventPoint grabbed in two different windows at the same time, but popups need event forwarding so maybe that was why (if a MouseArea triggers the popup, should it stay pressed and keep its grab? the subsequent mouse moves and the release need to be forwarded to the popup, so maybe something inside the popup needs a grab, simultaneously or not). Anyway we don't have actual popup windows in Controls 2 right now; and we know that event forwarding for popups needs work in QtGui so that it will be easier when we try again to have them in Qt Quick (QTBUG-68080). So perhaps the original workaround has outlived its usefulness: popup event forwarding needs to be handled at the lower layer, not in Qt Quick. Task-number: QTBUG-57253 Task-number: QTBUG-60123 Task-number: QTBUG-86729 Change-Id: I56dbc3bb94f66a7f26f79a97bcb2f2bbc0b7aa92 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_ma::pressedCanceledOnWindowDeactivate: don't pop up second windowShawn Rutledge2020-11-182-13/+2
| | | | | | | | | | | | | | I guess I must have thought it would be more realistic that way; but sending an explicit WindowDeactivate as we had it in early Qt 5 seems to keep the test passing now, and is probably more reliable. The original purpose of the test seems to be to verify the recursive delivery to all items via virtual QQuickItem::windowDeactivateEvent(), which MouseArea (and no other item!) overrides to ungrab the mouse. This mostly reverts commit 1c451b40aee66a38ca3d61e5beec4ae8c986c8ed. Change-Id: I0c6f953514095a491120a0aac9944dc8b04ca17d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-181-2/+2
| | | | | Change-Id: Ib6da28cb87975ead3e7c695d455639a39e3982cb Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* CMake: Match qmake generated resource name for qmldir filesAlexandru Croitor2020-11-181-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing static builds, mkspecs/qml_module.prf embeds the qmldir file and any additional foo.qml files into a generated Qt resource file. The resource name is called qmake_<qml_plugin_uri>.qrc. In turn, certain Qt modules and plugins code call Q_INIT_RESOURCE(<qml_plugin_uri>) to initialize the resources. When Qt is built with CMake there were 2 differences. Because the resource files are not compiled into the static libraries but rather passed around as object files, there is no need to call Q_INIT_RESOURCE() anymore. The second difference was that the generated resource name for resources containing the qmldir file was '<qml_plugin_uri>_qmldir'. The differences in the CMake build caused issues when linking a QtQuick3D example project with a static Qt. That happened due to the mismatch of the generated resource name in the Q_INIT_RESOURCE() call. Unfortunately these calls can't be removed during the build system transition phase because that would break qmake Qt builds. To fix this, change the name of the CMake generated resource to match the qmake name. This avoids the undefined symbol errors during linking, but is actually a no-op! That's because the global initializer in the linked resource object file will be called before the manual Q_INIT_RESOURCE() call, effectively making the latter a no-op. Note there is one more difference regarding the CMake build. The Qt CMake builds creates 2 different resource files, one for the qmldir file (inside qt6_add_qml_module) and another separate resource for qml files (inside qt6_target_qml_files). qmake in comparison creates only one resource file for both. In practice this shouldn't affect or break anything, because even if there is no explicit Q_INIT_RESOURCE() call for the qml files resource, the global initializer will still be called from the linked in object file. An issue might happen if there are qml files, but no qmldir file, because then the qmake-required Q_INIT_RESOURCE() would not be called due to the missing qmldir resource (as generated by CMake). I think such a scenario is very unlikely if not impossible. Task-number: QTBUG-88425 Change-Id: Ib12d93d0dae52785ba8182db6829f03524723ca7 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Record resource object file information for static buildsAlexandru Croitor2020-11-181-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | After any call to qt6_add_resources we need to record info about the resource object files. These will be embedded into the appropriate prl files to ensure that any application built with qmake links in the resources (only relevant for static Qt builds). The implementation is a bit ugly, but it gets the job done for now. It checks for the existence of an internal Qt function in the public macros and calls it if it's available. That will only happen when doing Qt builds. For regular app projects the functions will not be called, but we don't generate .prl files for such projects either way. Note that this comes with the same limitation as described in the changes for fixing QTBUG-88425. Specifically, the functions will only record resource object files for targets built as part of the current CMake invocation (aka just one repo for non-top-level builds). This handles the most common issues, but is not a complete fix. Task-number: QTBUG-87702 Change-Id: If632fdf9867cec4b24b1c6136d23ee9d8b56e650 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-181-2/+2
| | | | | Change-Id: I854332ef6d9ef327ece0c22bdf064dd83cb943aa Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* tst_qqmlproperty: Fix interfaceBinding crash on MSVC 2019Maximilian Goldstein2020-11-183-10/+31
| | | | | | | Change-Id: I4bb4a66b7ccca838e058962bbc297659b273c78e Done-with: Fabian Kosmale <fabian.kosmale@qt.io> Fixes: QTBUG-84416 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Mention a change in Qt Quick TestVolker Hilsheimer2020-11-181-1/+3
| | | | | | Change-Id: Id81fcbd8e6869239ad4625907819987463443d07 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Remove extra \endlist commandJerome Pasion2020-11-181-1/+0
| | | | | | | | -fixes qdoc warnings Task-number: QTBUG-86102 Change-Id: I2e2a2f98d7127629bedc06612d6c6b4f7e57fb52 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* CMake: Replace 'file' with 'configure_file' in 'qmldir' generationAlexey Edelev2020-11-183-3/+43
| | | | | | | | | | | | | | | Collect content of 'qmldir' file that is generated by 'qt6_add_qml_module' and 'qt6_target_qml_files' functions, instead of write content to file immediately. Use 'cmake_language(DEFER CALL)' to call 'configure_file' write whole 'qmldir', when finalizing CMAKE_CURRENT_SOURCE_DIR scope. This way a reconfiguration will not rewrite the files, touch the timestamps, and thus needlessly rebuild. Task-number: QTBUG-88172 Change-Id: Idca68e4ceed13d0aa7eac443e769d5677557b880 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Replace qt_make_unique with std::make_uniqueAllan Sandfeld Jensen2020-11-181-4/+3
| | | | | | | So we can remove it. Change-Id: I037373f85c696ce04c55920b41377cc9843b0da3 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Use metatype and remove unused variableDavid Skoland2020-11-183-4/+2
| | | | | Change-Id: I709c6a74dc6a3eb0cdd3e94168921274f90df4a4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QMutable*Event classes to copy and synthesize eventsVolker Hilsheimer2020-11-187-46/+45
| | | | | | | | | | QMutableTouch/SinglePointEvent can be publicly copy constructed from their non-mutable counterparts, make use of that. Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* pixmapcache: avoid deadlock when canceling async image loadNick Shaforostov2020-11-181-2/+2
| | | | | | | | was only possible if qml_network is disabled Pick-to: 5.15 Change-Id: If8a8addc0aa5c4c768dd7df3aa4d627f82a78059 Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* QQmlDirParser: Drop unneeded includeUlf Hermann2020-11-181-1/+0
| | | | | Change-Id: Iba9f99f0fcdb7692ceadaec223d82e425f1e424b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QmlCompiler: Fix resolution of method and property typesUlf Hermann2020-11-185-26/+56
| | | | | | | | | | | | | | | | We need to resolve the types for QML elements in two passes because only after finishing the parsing we have the QML-declared methods and properties available. We already need the base type before, though. Also, there can be multiple methods of the same name. We need API to access them. It also turns out that the internal name of the "var" type has to be QVariant in order to match reality. "var" properties and unnamed arguments to JS functions are implemented as QVariant. Change-Id: I541f11e96db72d832f4e4443d3a5d31079a56575 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-181-2/+2
| | | | | Change-Id: I7c5999f339e0d6ee25cc69d48296ddd51d529036 Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* tst_qmllint: Be more verbose when qmllint crashesUlf Hermann2020-11-171-0/+8
| | | | | | | Output the command line, exit status, exit code, stderr and stdout. Change-Id: I81a813bc44b7caf4c25d9097e8fbcbc3295ac6ec Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Porting Guide: Mention QQmlListProperty changeFabian Kosmale2020-11-171-1/+25
| | | | | Change-Id: I173e2ff05b3fc3bbe56df423abcbfc84bdc2a17a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* V4: Deal with AOT-compiled functions returning QVariantUlf Hermann2020-11-171-2/+11
| | | | | | | | In this case we need to pass a pointer to the return variant itself, not to its data. Change-Id: I86e468f106f29e1f1be8adee9882d465fd6da533 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix potentially missing endFrame() in threaded render loopLaszlo Agocs2020-11-171-0/+5
| | | | | | | | | | | | | | | | | Upon a QWindow destroy() and show() we can get to syncAndRenderer with sync not requested. It will be followed by a full sync+render request afterwards, but first we need to gracefully survive that somewhat obscure initial round (obscure because the window is fully usable, so we get a swapchain, but then we do not sync, so there is no QSGRenderer created) Exhibited by tst_qquickwindow::headless. It correctly showed a warning on all platforms and rhi backends, but was only fatal on macOS and Metal for some reason. Fixes: QTBUG-88513 Change-Id: I0396b648af0fd2bef2964b79a28359a7f806530d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove scene graph section that has only a dead linkVolker Hilsheimer2020-11-171-5/+0
| | | | | | | | Scene graph changes are documented in the section further down. Task-number: QTBUG-88152 Change-Id: I6362999e6830e05981e95af78b3d2f00b5e398e3 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix tests that used out-of-context mouse grabsShawn Rutledge2020-11-173-9/+8
| | | | | | | | | | QQuickItem::grabMouse() is deprecated, and cannot be used at all when there is no current event being delivered. But we can still use QPointingDevicePrivate::setExclusiveGrabber(). Task-number: QTBUG-86729 Change-Id: I215de471e6dc44551720bc4c766b22cdfee94423 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clean up tst_TouchMouseShawn Rutledge2020-11-171-424/+358
| | | | | | | | | | - The view-showing boilerplate is reduced - Uncommented and fixed up some statements that were failing at one time - Fixed override warnings - Use qCDebug not qDebug Change-Id: Ib437cc985c03776492da2502ecdb5176afadadf2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QQuickTest::showView(); give QQuickTest::initView() default argsShawn Rutledge2020-11-172-13/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now the boilerplate for most QML-using C++ tests can be reduced from QQuickView window; QByteArray errorMessage; QVERIFY2(QQuickTest::initView(window, testFileUrl("myitems.qml"), true, &errorMessage), errorMessage.constData()); window.show(); QVERIFY(QTest::qWaitForWindowExposed(&window)); QVERIFY(window.rootObject() != nullptr); to QQuickView window; QVERIFY(QQuickTest::showView(window, testFileUrl("myitems.qml"))); The idea to dump the QML error output was nice, but the engine already generates QWARN output like this (lines partially wrapped, URL elided for brevity): QWARN : tst_TouchMouse::touchPointDeliveryOrder() [ 0.000 W] default unknown - file:/...rder.qml:14:29: Cannot assign to non-existent property "pill" Rectangle { anchors.pill: parent; color: "lightsteelblue" } ^ FAIL! : tst_TouchMouse::touchPointDeliveryOrder() 'QQuickTest::showView(window, testFileUrl("touchpointdeliveryorder.qml"))' returned FALSE. () Loc: [/home/rutledge/dev/qt6/qtdeclarative/tests/auto/quick/touchmouse/tst_touchmouse.cpp(1343)] Improves on a804f31ee2665501c1894cbae8302db181090bd5 Change-Id: I92b8e3720bb5b1d009580bb74566690ad3d5292c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* When Flickable filters UngrabMouse, react as if it was ungrabbed itselfShawn Rutledge2020-11-173-8/+9
| | | | | | | | | | | | | | | | | | | | | Fixes tst_QQuickListView::touchCancel again. In this scenario, a TouchCancel is sent, but gets turned into an UngrabMouse for delivery to the MouseArea which is the current grabber. We try to avoid calling QQuickWindow::mouseGrabberItem() because it's too vague a question to ask (which mouse? or did you mean the synth-mouse during synthesis from a touch or tablet event?); and now it acts different anyway, because eventsInDelivery.top() is an UngrabMouse, which did not include a pointer to the QPointingDevice until now. So now we turn the UngrabMouse event into a QSinglePointEvent so that it's possible to get exclusiveGrabber() and check that the grabber is not the same Flickable. (Otherwise, the grabber that's getting ungrabbed is usually the child receiver item sent to childMouseEventFilter().) Task-number: QTBUG-86729 Task-number: QTBUG-74679 Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add tst_qquickflickable::parallelTouchShawn Rutledge2020-11-172-0/+110
| | | | | | | | | | | Prove that we can drag multiple Flickables with multiple touchpoints now. [ChangeLog][QtQuick][Flickable] Flickable now handles touch events directly: you can now drag multiple Flickables with multiple touchpoints. Fixes: QTBUG-30840 Change-Id: I0a3e58595a67f5afb4b93ad64d5280cb3fc52f7a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add tst_qquicktextedit::inFlickable testsShawn Rutledge2020-11-172-0/+126
| | | | | | Task-number: QTBUG-88169 Change-Id: Iaea3959365a580f3f8d2dd7ab2b227933e79cf59 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Avoid calling QQuickItemPrivate's methods if QQIP is incompleteFabian Kosmale2020-11-173-4/+27
| | | | | | | | | | | | | | | | In QQuickWindow, we instantiate QQuickPaletteProviderPrivateBase, which in turn instantiates its updateChildrenPalettes method, which then calls QQuickItemPrivate::inheritPalette. However, QQIP is an incomplete type at this point. Including qquickitemprivate_p.h would currently create a cyclic dependency, and breaking that dependency might mean outlining performance sensitive code. Thus we instead (ab)use the fact that updateChildrenPalettes is virtual, do nothing in the specialization for QQuickWindow and instead implement the method in the same way as an override in QQuickWindowPrivate. Task-number: QTBUG-88457 Change-Id: I49b357d7a67f1945a4d3c25e8cabd428d1454aa7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix incorrect assumptions with Metal in tst_qquickwindowLaszlo Agocs2020-11-171-4/+8
| | | | | | | | | Two cases fail due to attempting to query the MTLRenderCommandEncoder in a state where QRhi::beginPass() was not yet called. This is invalid and we should not test for it either. Change-Id: Ieaaaabd275db68be98365fb76a39f30a635d3543 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* tst_qqmlproperty: Skip crashing interfaceBindingMaximilian Goldstein2020-11-171-0/+3
| | | | | | Task-number: QTBUG-84416 Change-Id: I79048233041802fe74e28b07def5ca0a3181c358 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QV4Engine: Fix conversion of char16_tUlf Hermann2020-11-172-2/+18
| | | | | | | | This is a single char16_t, not an array of them. Pick-to: 5.15 Change-Id: I55d23ebb5f2abebd43cd4160a75d373706392ddf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Don't synthesize mouse from touch for items that accept touchShawn Rutledge2020-11-178-163/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that has acceptTouchEvents() == true merely fails to accept one touch event, that does not mean a mouse event should be sent. Finish changing the default to false: handling touch events is opt-in, just like handling mouse events; most items don't. And if you opt in, then you MUST handle touch events, because you will NOT receive mouse events as a fall-back. Now that Flickable handles touch, filtering multi-touch events becomes relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch when Flickable grabs a stationary touchpoint at the same time as another touchpoint is pressed, preventing a child PinchArea from reacting. So there's a new rule: just as we start over with event delivery when a new point is pressed, QQuickFlickable::filterPointerEvent() should also not immediately grab when any point is newly pressed; it can afford to wait, because it's filtering, so it will be able to see if one point is dragged past the drag threshold later on. When a parent (such as Flickable) contains only mouse-handling items (such as MouseArea), the parent should filter the touch event if it is able (if acceptTouchEvents() returns true). Flickable is now able to. Filtering parents that are not able to filter touch events can still filter a synth-mouse event as before. But filtering both must be avoided: then we would have the problem that Flickable filters a touch move, sees that it's being dragged past the drag threshold, and sets d->stealMouse to true to indicate that it wants to steal the _next_ event; then it filters a synth-mouse move, and that's perceived as being the next event even though it's just a different view of the same event, so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we rely on the delay caused by waiting for the next event: the MouseArea is trying to drag an item and the Flickable wants to flick; both of them decide on the same event that the drag threshold is exceeded. But MouseArea calls setKeepMouseGrab() immediately, whereas Flickable doesn't try to steal the grab until the next event, and then it sees the keepMouseGrab flag has been set, so it doesn't do it. If Flickable could filter the same event twice (once as touch, once as synth-mouse), this logic doesn't work, so it's effectively "more grabby" than intended. So it works better to have it filter only the actual touch event, not the synth-mouse that comes after. When the child has pointer handlers, we need to visit them, and therefore we should let Flickable filter a touch event on the way. tst_FlickableInterop::touchDragFlickableBehindButton() depends on this. [ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must explicitly call setAcceptTouchEvents(true) to receive QTouchEvents, and then it must handle them: we no longer fall back to sending a QMouseEvent if the touch event is not accepted. If it has additionally called setFiltersChildMouseEvents(true), then it will filter touch events, not any synthetic mouse events that may be needed for some children. Task-number: QTBUG-87018 Fixes: QTBUG-88169 Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-171-2/+2
| | | | | Change-Id: Ia7f63103a32fbdd0f80d77483893ee458b9fdd6e Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
* Update dependencies on 'dev' in qt/qtdeclarativeQt Submodule Update Bot2020-11-161-2/+2
| | | | | Change-Id: Id0eaa7a167ebd69ce568bd9c19a7c78ed276874b Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>