aboutsummaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Mark QQmlListProperty as a QML list in QMetaTypev6.0.0-rc1Fabian Kosmale2020-11-241-1/+6
| | | | | | | Change-Id: Icd92121bb65ffca1135c1ef69b90d8a8955c1df0 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit b788ef085c66d95aa75052c079d9d2fe15bc7f16) Reviewed-by: Qt Cherry-pick Bot <cherrypick_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-192-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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-181-2/+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>
* 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>
* tst_qqmlproperty: Fix interfaceBinding crash on MSVC 2019Maximilian Goldstein2020-11-181-2/+6
| | | | | | | 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>
* 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>
* 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>
* When Flickable filters UngrabMouse, react as if it was ungrabbed itselfShawn Rutledge2020-11-172-6/+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>
* 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>
* QV4Engine: Fix conversion of char16_tUlf Hermann2020-11-171-1/+1
| | | | | | | | 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-173-17/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add past major version 1 to QtQuick.tooling and 6 to its componentsUlf Hermann2020-11-162-1/+11
| | | | | | Change-Id: I09e29b85949eac270c6cee711408b8a09dea79a8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
* Don't copy or assign QEvent instances in testsVolker Hilsheimer2020-11-161-11/+20
| | | | | | | | | | | | | | | Copying/assigning polymorphic types is a code smell, use separate instances instead in the tests. Those should perhaps be rewritten to use a data driven testing approach, there's a lot of code repetition. In the test API implementation, first evaluate the parameters for the event, then construct the event once with the correct values. Change-Id: I2572772698cb0204f5ff950741b9fe3805fae15d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Don't copy QKeyEvent instances, store the data explicitlyVolker Hilsheimer2020-11-162-17/+45
| | | | | | | | | | QEvent is a polymorph type, and even though it has a copy constructor, we shouldn't use it. Use the pattern as in QQuickMouse/WheelEvent. Change-Id: I26ab7b831e1e8dd156c32417f74bc7d800bcf71c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do generate typeinfo qmldir entries for pure QML modulesUlf Hermann2020-11-161-3/+1
| | | | | | | | | | As we generated qmltypes files (albeit empty), we also have to advertise them in the qmldir files. Otherwise qmllint will complain, as that is a common mistake in old modules where qmldir files were written manually. Change-Id: I4c96610930d89558cd363b7f9db28ec6e21ed4d5 Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* YarrParser: compile with explicit QChar(int) constructorDavid Faure2020-11-151-7/+7
| | | | | Change-Id: I10d30d1ba83f8db9568cef18a32baac1627b2c17 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Add logging category qt.quick.pinchareaShawn Rutledge2020-11-131-2/+10
| | | | | Change-Id: Iacfffdc774d5ea6980af7a29da07a82f17799e33 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickWindow: better hover debug, and a reminderShawn Rutledge2020-11-131-1/+7
| | | | | | | | | | | | | In the qt.quick.hover.trace category, the position is the most important thing for now. The output for "q" is verbose and usually there's only one window anyway, so just put the title last, in case we need to debug a multi-window scenario. Dealing with hover in multi-device scenarios is going to be interesting one of these days. Change-Id: I2b687085432ce2e02ca764b8b4669282e0180c54 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QmlCompiler: Mark dataPtr as unused for void AOT functionsUlf Hermann2020-11-131-0/+1
| | | | | | | Otherwise we get lots of "unused" warnings from the compiler. Change-Id: I7744715c476350dd3bba34500589cb1c62672c9f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* tooling: List the actual QML files in the qmake projectUlf Hermann2020-11-131-3/+8
| | | | | | Fixes: QTBUG-88471 Change-Id: Ifc023fdc82b728931ff88c0c634ad71e2b2995a2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmltyperegistrar: Use QString rather than string for stringsUlf Hermann2020-11-121-3/+5
| | | | | | | | All other type names are actual C++ type names. Also, correctly resolve qreal if its type is overridden at configure time. Change-Id: Ia2a1b4309f94e8c72461ee69005b1bdee6337370 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add a module describing the qmltypes formatUlf Hermann2020-11-1213-1/+428
| | | | | | | | | | It's turtles all the way down. And now we can verify builtins.qmltypes using qmllint. Change-Id: I10c98ff8837c04838c3fd9803ef4ea0fd5d7bd0e Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Change Quick.Window into a pure Qml moduleAlexandru Croitor2020-11-124-7/+53
| | | | | | | | | | | This fixes apps using Qt.Window with static Qt builds when deployed to a machine that doesn't have Qt installed. This will need a counterpart fix in qmake land. Change-Id: Ife11f9d1f1826e1188ef3dc3933af2f243860b6f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Allow building pure QML modules not backed by C++ sourcesAlexandru Croitor2020-11-124-21/+110
| | | | | | | | | | | | | | | | When no C++ sources are passed to qt_internal_add_qml_plugin (a pure QML module), create a C++ backed Qt plugin anyway. In such a case, generate a dummy plugin.cpp containing a QQmlEngineExtensionPlugin subclass. The class name is autogenerated from the QML import URI. The class constructor will call the qmltyperegistrar generated void qml_register_types_foo() function, to ensure the needed module versions are registered for the QML module. Change-Id: I19959dafdf0dc837c6037e7dc1d549b7420110a7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QmlCompiler: Add method to get first non-composite base scopeUlf Hermann2020-11-121-0/+9
| | | | | | | That's a recurring thing. Change-Id: I8dc049a559e337c70089dd1f81ff23bf7d2140fe Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlEngine::captureProperty(): Don't capture constant propertiesUlf Hermann2020-11-121-1/+1
| | | | | | | That is a noop and produces a warning. Change-Id: I75787aee66b55522005247524140e3f3a7dd56ba Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlListModel: use alignof for alignmentFabian Kosmale2020-11-121-1/+1
| | | | | Change-Id: I1dac3e33289516ec677d6db0d8d7cf1e02addc16 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Allow removing attractor particlesystem at runtimeKaj Grönholm2020-11-123-2/+19
| | | | | | | | | Don't crash and make it work as expected. Task-number: QTBUG-37491 Change-Id: I0b94fdfa0a79dd43b762b03b24e3415762eecd95 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QmlCompiler: Correctly store AOT functionsUlf Hermann2020-11-121-2/+5
| | | | | | | | There always has to be an empty last function. Otherwise we might access invalid memory when loading them. Change-Id: I5e7a784c14ac8a12450926b895664a98c03f85f1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Take pixel ratio into account with point particlesKaj Grönholm2020-11-1216-1/+16
| | | | | | | | | | | | Particles using DrawTriangles are taking pixel ratio into account, while particles using DrawPoints used raw pixel sizes. Change points to also scale based on dpr. This way particles with different backends and performance levels remain the same size. Task-number: QTBUG-88240 Change-Id: I3988a0ad8e741626a56a41b08aed0500e5be0c62 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QQuickView docs: show correct usage of setInitialPropertiesFabian Kosmale2020-11-122-0/+13
| | | | | | Pick-to: 5.15 Change-Id: If63f4c59f18bc0754ce2e68e424f6efd0f512d30 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QmlCompiler: Store values QQmlJSMetaEnum when availableUlf Hermann2020-11-123-1/+26
| | | | | | | | | | | | | When parsing QML files, we need to keep the enum values around as this is the only place where we can find them (without parsing the same file again, that is). With C++ types we don't strictly need them as they are also available from the C++ header, but if the qmltypes file is nice enough to provide them, we can use them. (Which will be for types that are not actually C++ types, but rather types produced by registering a QML file with qmlRegisterType()). Change-Id: Ibcc93b30e523a00e1eeb80029943c48b83d0e1b5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use QDate::startOfDay() rather than QDateTime(,QTime(0, 0),)Edward Welbourne2020-11-121-3/+2
| | | | | | | | Makes no difference in this case, as it's UTC, but is terser and perhaps slightly clearer. Change-Id: I7de315def2f45ec4a12d2a682e5d1d7a4d0a3e6d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 03:13:43 +0000