summaryrefslogtreecommitdiff
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* Polygons/lines can now be rendered following the shortest path on the globeMatthias Rauter2023-04-1132-33/+506
| | | | | | | | | | | | | | | | | | | | | | This is enabled by interpolating the lines of polygons and paths. The interpolating is done following the greater circle navigation and the connection between corners of the polygon appear curved on the projected map. This behavior can be turned on by setting a new property, called referenceSurface. It can be set to ReferenceSurface.Map, drawing paths as lines on the map or to ReferenceSurface.Globe, drawing path on the globe leading to curves on the map. It is set to ReferenceSurface.Map on default, reproducing the old implementation for polygons, polylines and rectangles. The circle item was already using the great circle path before this change. Its standard implementation was changed to draw a circle in map coordinates with approximated radius. This should be sufficient for many cases. To get the old implementation, referenceSurface has to be set to ReferenceSurface.Map. Fixes: QTBUG-94785 Change-Id: Ifdd1597a7116c3d220462f063656b04becb6422f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add boundaries to zoomLevel in MapViewMatthias Rauter2023-02-221-2/+2
| | | | | | | | | There was a bug in the notification handling in QDeclarativeGeoMap that prevented BoundaryRule to work properly. This bug was fixed along the way. Pick-to: 6.5 Change-Id: Iae85019c7cceb77dab6f20478b564908797f7ccd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add baseline tests to qtlocationMatthias Rauter2023-02-1532-0/+2183
| | | | | | | | Testing rendering of QDeclarativeMapItems. Pick-to: 6.5 Change-Id: I9767314945a022006fdf02341744018c04206099 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add benchmark example for DeclarativeMapItemsMatthias Rauter2023-02-158-0/+571
| | | | | | Pick-to: 6.5 Change-Id: I42ec79a55eb16d768a3268212272cd06436d24b9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use SPDX license identifiersVolker Hilsheimer2023-02-02129-3483/+258
| | | | | | | Task-number: QTBUG-67283 Pick-to: 6.5 Change-Id: I4b8f877cc355c7c6cd410b3b1683defa58486381 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add MapViewShawn Rutledge2023-01-288-456/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has nearly complete functionality now. A couple of approaches were possible: one way is to have the Map larger than the MapView, so that the MapView defines a viewport. This allows the handlers to function more "normally": DragHandler already knows how to move the Map in the viewport, etc. But then you can pan off the edge of the Map; so we needed a recenter() function to calculate and set the map.center property, and call that at the right times. This needs to be done when the MapView is resized too, and that turned out to be tricky to get right. Another advantage though would be that we could ensure Map doesn't re-generate geometry any more often than necessary: small changes to the center and scale of the map would often merely change one QSGTransformNode. We could still try this approach again later on, but perhaps Map should be doing more of the work to make it possible; and the new ItemObservesViewport flag ought to be useful. But for now, we do it the existing way: Map does its own viewporting. Thus, we assume that Map is optimized to limit geometry re-generation internally. In practice, redrawing while executing a pinch gesture feels fast enough. One of the main reasons we needed the recent changes in handlers is to get deltas. We cannot use bindings directly from handler properties to Map properties, because there are multiple ways to modify each property (you can zoom by pinch or wheel in MapView, and probably via a keyboard shortcut in the application), so we need to increment the zoomLevel and bearing properties rather than binding them. When it comes to panning: instead of a property, Map has a pan(dx, dy) invokable function; so we call that in response to the DragHandler.translationChanged signal, which now carries a delta-vector argument. The alignCoordinateToPoint() function turned out to be ideal to make the pinch gesture zoom into and rotate the map around the centroid (the point between the touchpoints). Since we call that function when either the rotation or scale changes, we do not need an onTranslationChanged(), because you can't do a pinch gesture that only pans without also changing scale and rotation slightly. All three signals are firing constantly, so handling two of them is enough. The Vector3dAnimation turned out to be a good fit to get flicking momentum (let the panning continue a little while after the finger is released); needing to use the pan() function here is a little clumsy, but we can live with it. Handlers and Animations would both prefer to set properties directly. But if there were a property, it would tend to have type QVector2D or QPointF, and the Vector3dAnimation wouldn't know how to set it anyway (but that could be hacked in, or we could write a Vector2dAnimation). Calculating the limits for zooming seems to be tricky: Map.minimumZoomLevel is zero, but in practice the minimum zoom depends on the size (because we cannot zoom out so far that the map no longer fills the viewport, but if the viewport is smaller, then you can zoom out further). So PinchHandler currently limits the max zoom fairly well, but when you try to zoom out too far, it is Map rather than PinchHandler that applies its own runtime limit. That makes PinchHandler.persistentScale useless; but now PinchHandler applies only incremental zoom deltas, so it doesn't matter. But WheelHandler cannot apply limits on its own, so currently it lets you zoom in too far. Map stops you from zooming past level 30, which is strange, since it already knows that OSM maps are limited to level 18. So either we need to figure out how to calculate both the min and max accurately so that we can apply BoundaryRule (which will also replace the use of PinchHandler's own limits, and will depend on a fix for PinchHandler to work with BoundaryRule), or we can get Map to enforce the lower limit: 18 instead of 30. A little bit of zooming beyond 18 is ok (for example to 20), but if you go even further, the rendering suddenly disappears. This could be done in a followup patch, and a couple of autotests need fixing then. The incremental zooming is treated as base-2-logarithmmic, although that's an approximation: https://wiki.openstreetmap.org/wiki/Zoom_levels tells us that sometimes one zoom level corresponds exactly to zooming 2X, but going from zoom level 16 to 15 is an 8:15 ratio. It's close enough to feel smooth anyway; and it turns out that Map is rendering fractional zoom levels well enough already. If that were not the case, we'd need to bring the Item.scale property into play. Now that the Map is the same size as the MapView, we have a choice whether the root of MapView should be a wrapper Item or not. The root could be Map itself, with handlers inside; the upside would be that all Map properties are left exposed. The downsides would be losing the opportunity to go back to the other architecture later on (with the root defining a viewport, and rendering a larger map inside, but re-rendering less often), and losing the opportunity to make the view's minimumZoomLevel and maximumZoomLevel different than those in Map itself. As explained above, minimumZoomLevel should depend on viewport size. So perhaps it's better to keep it like this: we have control over which Map properties to expose directly, and for the rest, the user can bind to things like mapview.map.center instead of mapview.center. The geojson example is updated to use MapView, whereas minimal_map applies its own handlers to the Map. Other examples still need updating. [ChangeLog][MapView] MapView is the interactive replacement for the Map item in earlier releases. It wraps a Map instance with pointer handlers to make it interactive. Pick-to: 6.5 Fixes: QTBUG-68108 Change-Id: Ibf6bcf71fa7588fcf8cf117e213f35cebd105639 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix the broken test after the retirement of qt_parse_all_argumentsAmir Masoud Abdol2023-01-211-1/+1
| | | | | | | | | | As we are now processing the arguments with cmake_parse_arguments(PARSE_ARGV, we don't need to pass the escape characters anymore. Task-number: QTBUG-99238 Change-Id: I618d4cd0105988bffb1d496fa2b3149d0e609710 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Remove unused extraParametersVolker Hilsheimer2023-01-133-36/+0
| | | | | | | | | No plugin implements or uses it, and we could use dynamic properties to pass more data through to backend implementations, if needed. Pick-to: 6.5 Change-Id: Ie7cbc1e24fadf51e5f39e0ced53860e6a2c6609b Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Mark the module as free of qAsConst()Marc Mutz2022-12-072-2/+2
| | | | | Change-Id: Ie67ec9b4f1f808b3b70ca7beb98f90c9cd1f2a9f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove map item backend switchLaszlo Agocs2022-11-303-101/+0
| | | | | Change-Id: Ic1ed064269ac73e68d0358b373ea1e8048a1c241 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QDeclarativeGeoWaypointVolker Hilsheimer2022-11-281-40/+15
| | | | | | | | | | | | The type was introduced as a QML-wrapper around QGeoCoordinate, which is now a registered value type for QML. QGeoCoordindate doesn't have a bearing property, but as waypoints could be initialized with a list of QGeoCoordinate anyway, 'bearing' was only inconsistently supported. If we want to bring that back, then it might be best to add an optional bearing to QGeoCoordinate in Qt Positioning. Change-Id: I3d8cb64f3552dc5580945b17c3a9092a7205b9b8 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Revive mapitems_backends manual testLaszlo Agocs2022-11-151-22/+16
| | | | | | | | Fix up the imports so that the qml file loads. Then follow the changes for the available polyline backends. Change-Id: I01a229264275ef0b89eb71332b06da0be0097b08 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Revive mapobjects_tester manual testLaszlo Agocs2022-11-151-19/+14
| | | | | | | | Fix up the imports so that the qml file loads. Then follow the changes for the available polyline backends. Change-Id: Idbf4049523ddd8d6857911f76e973a7e24064b42 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Simplify by removing the LineStrip mode for MapPolylineLaszlo Agocs2022-11-151-6/+4
| | | | | | | | | | | | | | | | | | | | | | Have two modes (Software, OpenGL) for polyline, as it is the case for all other items (rectangle, circle, polygon). OpenGLLineStrip is removed completely, whereas the enum value OpenGL is added with the same value as OpenGLExtruded for symmetry with other items. Drawing lines and expecting wide line (width > 1) support to be avilable is highly non-portable: Direct 3D, Metal, and core profile OpenGL contexts will not support widths other than 1, whereas with Vulkan wide lines are an optional feature so it may or may not work. As the 'backend' property is already marked as internal, it won't present any consequences when it comes to the public API. Internally this requires some untangling of the somewhat intertwined node and material implementations. Change-Id: I175ddb5f84128ed4d0fcf2939272e631566ff327 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove parameterization functionalityVolker Hilsheimer2022-11-025-169/+17
| | | | | | | | | | | | | | | | | | | | | The abstraction of plugin-specific parameters makes little sense if we don't want to provide a cross-backend API. So remove this for now. If in the future we want to attach meta-data or backend-specific properties to values or element types, then we might be able to use existing QVariantMap type properties (like QGeoRouteRequest's extraParameters, via QDeclarativeGeoRouteQuery::extraParameters), or register backend specific QML types that applications can opt in to use. This requires a bit of research and experimenting based on specific use cases. If we can't come up with anything better, then bringing back a, perhaps simplified, version of the infrastructure removed here will still be an option. Change-Id: If590a35f2ffb80b0c918d866e88913a9caf75d2b Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Disable Esri/Nokia/MapBox pluginsVolker Hilsheimer2022-10-253-76/+90
| | | | | | | | | | | | | As a first step, put them behind feature flags that are always false. Remove mapbox-gl-native as a submodule - there's no reason why people wanting to build that can't clone and build that repo themselves. Don't test the respective providers unless they are available, and use the osm plugin when testing the basic plugin framework. Change-Id: I53429878e53294dce52ee830a4b4613f372898c6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* tst_QGeoTiledMap: fix memory leakIvan Solovev2022-10-061-4/+6
| | | | | | | | | Use std::unique_ptr to manage QGeoServiceProvider object's lifetime. We cannot create the provider on the stack because it must outlive the child QGeoTiledMap instance. Change-Id: Ic2275fda394175bcb2a7782f887c10326f4c72a0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* tst_QPlaceSearchRequest: fix memory leakIvan Solovev2022-10-061-5/+5
| | | | | | | No need to dynamically create the QPlaceSearchRequest instance. Change-Id: If82213b2019741ae302be2b67b71d56187822bda Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Register QGeoRoute as QML value type, remove QDeclarativeGeoRouteVolker Hilsheimer2022-10-044-15/+14
| | | | | | | | Adapt model and tests accordingly. Fixes: QTBUG-106482 Change-Id: Ie5a36e4fef17ae7bc4ecfab9187a325fb025e283 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Declare value types as structured values, remove workaroundsVolker Hilsheimer2022-09-305-23/+18
| | | | | | | | Use QML's new support for initializing structured values, adjust tests, and remove the now unnecessary conversion functions. Change-Id: I7007c9acb50f4a9532a9eed847b1b4dd0928ba34 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Build system: move to declarative type registrationVolker Hilsheimer2022-09-282-4/+4
| | | | | | | | | | | | | | | | | | | | Adjust the build system accordingly, attaching a QML module with the respective implementations to the QtLocation target. An explicit function is still needed to register converters, and will be removed once the improved support for value types has merged. This should enable the qml compiler to generate C++ code, which then requires linking against the library. The MapParameter type was renamed to DynamicMapParamter as per the 5.11 change log, so remove the MapParameter alias now and adjust tests. Task-number: QTBUG-106886 Change-Id: Id8765c1bc3b98d447d768b246b21a16f71bfdf74 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Simplify Q(Declarative)GeoMapParameterVolker Hilsheimer2022-09-263-27/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Move the initialPropertyCount to the QGeoMapParameter class, where previously the 2 was hardcoded. Don't make type/setType virtual, as the subclass doesn't override those methods anyway. Remove the unused constructor taking a list of property names and values. In QDeclarativeGeoMapParameter, optimize the dynamic connections between property notification signals and the generic forwarder. Connect between QMetaMethods, which avoids the repeated lookups, and give the SignalMapper instances the QMetaProperty as a data member so that we avoid the lookup of the signal for each signal emission, and only need one connection per property, rather than two. Also, remove the empty destructor and apply const where appropriate. QDeclarativeGeoMapParameter is used only by QDeclarativePolyLineMapItem, where support for the respective parameters, penStyle and penCap, is not implemented in the rendering code. None of the other map items support any such dynamic parameters, their support is not documented, and only used in the mappolyline manual test. So remove all that code. If we want to support more properties, then the QDeclarativeMapLineProperties type gives us that infrastructure already. Change-Id: Iddaac568a7dc09deb0bb5085b5b90c3cca0fa5ca Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Remove MapObjects from labsVolker Hilsheimer2022-09-261-162/+3
| | | | | | | | | | | | | | | The feature was designed to enable map backends to implement their own rendering of the map, and map items. It was never really used by any of the backends we supported, and introduced a lot of complexity to the code base. The idea as such has perhaps merit, but for now we focus on the basic functionality of Qt Location. Support for Qt Location when the Qt Quick scene graph is not used is not a part of that. Change-Id: I08e460043a0bd2600bad79b6ce2bb18e40e19eb6 Reviewed-by: Alex Blasche <alexander.blasche@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Rename Nokia HERE specific testVolker Hilsheimer2022-09-231-1/+1
| | | | | | | | Analog to tst_nokia_routing, call this test tst_nokia_places although there is also a tst_qplacemanager_nokia test that is not semi-automatic). Change-Id: I03ed29463b4877acfbd87953faaca1fd9b1cdfe7 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Stabilize flaky testsVolker Hilsheimer2022-09-221-2/+1
| | | | | | | | When testing model resets, wait until it reports data using tryVerify instead of a hardcoded single milisecond. Change-Id: Id3f3464f54a2b05e25c602594357e767eb8bbdba Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Fix warning in manual testsVolker Hilsheimer2022-09-223-6/+6
| | | | | | | ... and fix usability for rotation testing. Nice to get back to 0 again! Change-Id: I9985721b0af993ff19d0808c29ac7ab617d3559a Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Cleanup: QPlaceContent and subclasses (3/3)Volker Hilsheimer2022-09-221-0/+1
| | | | | | | | | | | | Remove the dedicated declarative model implementations for the special QPlaceContent types. Since everyhing is now a QPlaceContent, the generic model can return all the data, depending on which QPlaceContent::Type it has been created for. For QML clients, nothing changes. Change-Id: I7c8c02dc5986f4223b8f112dc5766ce073a41a4d Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Cleanup: QPlaceContent and subclasses (2/3)Volker Hilsheimer2022-09-227-443/+0
| | | | | | | | Remove deprecated APIs entirely, and add them as gone to the changes documentation. Change-Id: If55339881142b0fddc3f045d8c5a0eca0490c727 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Cleanup: QPlaceContent and subclasses (1/3)Volker Hilsheimer2022-09-226-275/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QPlaceContent and subclasses are value types, and subclassing value is a bad idea, for many reasons. Great care had been taken to work around the slicing problem, resulting in lot of code and complexity. Instead of the slicing problem, we now have the problem that we can assign a QPlaceContent item to a QPlaceImage and back, but that same QPlaceContent object can also be assigned to a QPlaceReview and a QPlaceEditorial item. Those then end up as empty items. So while it seems convenient to have C++ types, we replaced compile errors or explicitly dynamic APIs, like QVariant, with implicit conversions that require explicit type checks before, with the risk of silently losing data. Ironcially, applications access those different values then through various QAbstractItemModel implementations - which return QVariants anyway, requiring explicit type checking and coertion. And the C++ convenience is exclusively interesting for backend implementors, who anyway need to parse data and identify types dynamically. What we really need is a map of QVariants, and some information about what kind of data we can get out of the map. So as a first step in cleaning, replace the data storage with such a map and remove all the subclass specific privates, together with all the complexity (virtual functions, QSharedDataPointer::clone template specializations, macros). The subclasses themselves become very thin API wrappers. Their only special feature is that they all can still be constructed from a QPlaceContent instance. We need this for compatibility. With all the convenience C++ APIs marked as deprecated, people can still use those when using Qt 6.2-compatible Qt Location, and use the warnings to prepare for Qt 6.5 where we can then remove those APIs entirely. Change-Id: Id75f55d784fbe214a0db93d3c1f786209ef0a690 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Cleanup: de-virtualize QGeoRoutePrivateVolker Hilsheimer2022-09-222-35/+5
| | | | | | | | | | | | | | | The possibility to override this type in plugins was used for metadata that might just as well live in the extended attributes. And the usecase of making the basic passing of data from a private through a public type does not justify the overhead, and can be solved by simply initializing the value in the test plugin through the public setter. So remove this; if this is really needed for anything, then we can bring it back later. Change-Id: Iad8689b54f64fa89535d0ebc3c399b4fd054f9d7 Reviewed-by: Alex Blasche <alexander.blasche@qt.io> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Simplify declarative wrapper of QGeoRouteVolker Hilsheimer2022-09-221-1/+4
| | | | | | | | | | | | | | | | | | | | | Move the logic of counting, and assembling a list of segments into the QGeoRoute implementation, using a generic function that iterates the linked list of segments and calls a functor. Remove the (premature - how many legs are there - 5?) optimization of caching the list of legs and segments. For extended attributes, return the QVariantMap from QGeoRoute rather than building a declarative map (that is then supposed to be CONSTANT). Make the getters const. The only thing stopping QGeoRoute to be directly exposed to QML and the declarative wrapper to be removed is now the access to the routeQuery object. Change-Id: Ie9b86c3b235a75f3bbea086697a6eda02b060264 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Cleanup: More nullptr instead of 0Volker Hilsheimer2022-09-196-12/+12
| | | | | Change-Id: I6316384be07f1d0634860c3ddcbe85455e218fed Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Cleanup: de-virtualize QGeoCodeReplyPrivateVolker Hilsheimer2022-09-191-32/+1
| | | | | | | | | | | | | | The only call to the single virtual function, extraData(), was commented out. The subclass in the OSM plugin only wrote extra data for debug runs and the subclass in the mock plugin is never used to test anything anyway. So remove all this overhead. As a drive-by, refactor to member initialization and use qsizetype for members that refer to indices in a QList. Change-Id: I600b4637bc367ae45d51b2a7f9a3ae0b78fb77c4 Reviewed-by: Alex Blasche <alexander.blasche@qt.io> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Add CMakeLists.txt for manual tests subdirectoryIvan Solovev2022-09-161-0/+6
| | | | | | | ... so that they are shown in the build tree Change-Id: Ib073c8792d8ca938e55281321cd0b728e87c261d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Register QPlaceContactDetail as a QML value typeVolker Hilsheimer2022-09-153-40/+35
| | | | | | | | | | | | | | | Make QPlaceContactDetail a gadget, and register it as a value type with the QML engine. Remove declarative wrapper, and consolidate the documentation. Adjust the tests and remove tests that verify that the type behaves like an object. Initialize contactDetail properties as a grouped property. The QDeclarativeContactDetails implementation of QQmlPropertyMap has to stay, so rename the sources accordingly. Change-Id: I473d29405963bbe594cd5f26168a237c189d1d3e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Register QPlaceSupplier as a QML value typeVolker Hilsheimer2022-09-154-50/+28
| | | | | | | | | | | | | Make QPlaceSupplier a gadget, and register it as a value type with the QML engine. Remove declarative wrapper, and consolidate the documentation. Adjust the tests and remove tests that verify that the type behaves like an object. Initialize placeSupplier properties as a grouped property, or via a converter from QJSValue. Change-Id: Id35ac1d9f03ce831013e4a7231302abd7b6cd7c8 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Change QJSValue properties to QList<QGeoCoordinate/Rectangle>Volker Hilsheimer2022-09-152-5/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QML engine is able to operate on lists of gadgets, there is no need for using private APIs to operate on QJSValue. For the time being, this breaks a QML construct like path[0].longitude = 0 This no longer changes the value of path[0].latitude in place. Instead, use var path0 = path[0] path0.longitude = ... path[0] = path0 This is consistent with other properties that have type list<gadget>, as QML operates on copies of values, not on references. Adapt the test case accordingly. Since support for value-initializing properties of type list<gadget> requires plumbing in the QML engine, and registration of conversion routines from QVariantMap to QGeoCoordinate, augment the test. Remove the now unnecessary toList/fromList conversion functions, and the dependency to private QtQml libraries. Fixes: QTBUG-105241 Change-Id: I8f248c457a6de27a3b2680bdc948c5683ebc7fa0 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Register QPlaceIcon as a QML value typeVolker Hilsheimer2022-09-147-143/+18
| | | | | | | | | | | | | | | Make QPlaceIcon a gadget, and register it as a value type with the QML engine. Remove declarative wrapper, and consolidate the documentation. Adjust the tests and remove tests that verify that the type behaves like an object. Initialize placeIcon properties as a grouped property, or via a converter from QJSValue. That converter is a temporary solution to enable tests, and can hopefully be removed once the QML engine supports property-initialization of value types. Task-number: QTBUG-106482 Change-Id: I2aa29102ee232afb3d71396bcd3288e2f99c0fc6 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Register QPlaceAttribute as a value typeVolker Hilsheimer2022-09-143-14/+25
| | | | | | | | | | | | | | Make QPlaceAttribute a gadget, and register it as a value type with the QML engine. Remove declarative wrapper, and consolidate the documentation. Keep documentation for the ExtendedAttributes QML type together with the placeAttribute QML value type for now. Adjust the tests and remove tests that verify that the type behaves like an object. Initialize placeAttribute properties as a grouped property. Task-number: QTBUG-106482 Change-Id: Ia514ba4b2ae7f7af56dc0bcee19dca6dddbfd9cf Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Register QPlaceRatings as a value typeVolker Hilsheimer2022-09-144-52/+21
| | | | | | | | | | | | | | | | | | | Make QPlaceUser a gadget, and register it as a value type with the QML engine. Remove declarative wrapper, and consolidate the documentation. To support QML tests setting ratings properties from literal values, register a converter from QJSValue. That is temporary and will become obsolete once the QML engine can property-initialize, and perhaps even instantiate, value types. Adjust the tests and remove tests that verify that the type behaves like an object. This is not entirely complete (some tests still compare Place.ratings with `null`, but those tests pass for now, and will be changed in later commits when more types get converted in this way. Task-number: QTBUG-106482 Change-Id: I3694df414bb87adcfda3dc4b88e5206d4272bb82 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Register QPlaceUser as a QML value typeVolker Hilsheimer2022-09-142-23/+10
| | | | | | | | | | | Make QPlaceUser a gadget, and register it as a value type with the QML engine. Remove declarative wrapper, and consolidate the documentation. Adjust the tests, remove tests that test that the type is not a value. Use grouped properties initialization syntax in QML for now. Change-Id: I0c840911316590b7ba103e26fa99d824bb9e39c5 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Cleanup: use nullptr instead of 0Volker Hilsheimer2022-09-133-11/+11
| | | | | Change-Id: I2f713a9a88023c5e2b3d779ebe73c821c72dd0e3 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Merge the factory versions into oneVolker Hilsheimer2022-09-121-3/+3
| | | | | Change-Id: I24ebd31750c95163d099c6f2daad2c96f468a515 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Remove unused QDeclarativePeriod header and QPlacePeriod testVolker Hilsheimer2022-09-121-116/+0
| | | | | | | | Those classes are neither implemented nor used anywhere. Pick-to: 6.2 Change-Id: I65e3d7be4e67a732e7ba4d2d9998699f77c7f2eb Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Fix whitespace in testVolker Hilsheimer2022-09-121-61/+61
| | | | | Change-Id: Icd54be6353d723a0a7d27bb69c36e318dff7f6f4 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Cleanup: remove virtual keyword from overridesVolker Hilsheimer2022-09-127-15/+15
| | | | | Change-Id: Iac3ac030809f57cfcffbfcc3257551efb6c1ff0f Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Remove QDeclarativeGeoRouteSegment wrapperVolker Hilsheimer2022-09-091-1/+1
| | | | | | | | | | | | | | | | | | | Register the QGeoRouteSegment gadget type directly as the routeSegment QML type (via a Foreign), and use it in QDeclarativeGeoRoute. The type is now uncreatable. It wasn't in 5.15, but since there is no setter-API that is exposed to QML, there is no reason to have it be a creatable type. Adjust the QML test to declare a property of type routeSegment instead. Move the QML type documentation into QGeoRouteSegment, and document the corresponding C++ properties via \property. Unify the language a bit, and follow up on the rename from RouteSegment to routeSegment. Pick-to: 6.2 Change-Id: I1ebae0c1a9d056aa59510a3ab539b1d8bce8c6c7 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Don't use deprecated APIs in examplesVolker Hilsheimer2022-09-023-6/+0
| | | | | | | | | AA_EnableHighDpiScaling has no effect, High-DPI scaling is always enabled in Qt 6. Pick-to: 6.2 Change-Id: If96d9fa94b1248ab5bd6b7800e92df82aaec6ac9 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Remove QDeclarativeGeoManeuverVolker Hilsheimer2022-09-012-3/+3
| | | | | | | | | | | | | | | | | | | | | | Register the QGeoManeuver type directly as the RouteManeuver QML type, and use it in QDeclarativeGeoRouteSegment. The type is now uncreatable. It wasn't in Qt 5.15, but since there is no setter-API that is exposed to QML (QDeclarativeGeoRouteSegment::maneuver is a read-only property tagged as CONSTANT), there is no point in creating a RouteManeuver object in QML anyway. The QML tests can get a default-created QGeoManeuever from an empty route segment. Document the C++ properties via \property, move the QML type documentation into the qgeomaneuver.cpp file, and unify the language. Note: The QML type should be routeManeuver, as value types should start with a lower-case character. If we make that change, it will be in a separate, compatibility-breaking commit for all the value types. Pick-to: 6.2 Change-Id: I277e7011f2082e2da9e0141db9bad0a60a524c88 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Silence warnings in map_mouse testVolker Hilsheimer2022-08-301-18/+18
| | | | | | | | | Qt 6's QML no longer supports implicit function parameters in signal handlers, so declare them explicitly and use arrow-function syntax. Pick-to: 6.2 Change-Id: I5ffc14b4140d78c4f1dcc51aa5ca8f2d4e38d1d5 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
View Lorry Controller Status