aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/qml/qqmlpropertyvalidator.cpp
Commit message (Collapse)AuthorAgeFilesLines
* qqmlpropertyvalidator: Mark new warning as translatableFabian Kosmale2024-03-271-1/+1
| | | | | | Change-Id: I51bb9ca1e8dab6768fc2e85b53a4a6a3aab3a56d Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* Engine: Handle grouped property bindings of non-registered typesFabian Kosmale2024-03-271-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible to expose a type to QML which exposes a QObject (derived) property, which then gets used to create a grouped binding. The type of the property might not have been registered in QML, or it might be part of a base class which exposes the type already in another module. If that module is not imported (or does not exist at all), the property creator would so far bail out. Simply skipping the check would lead to crashes further down, as we also lack the property cache needed during object creation. However, in Qt 6, we can lift this restriction: We can retrieve the property's metatype, and from there we can fetch the metaobject. Once we have the metaobject, we can on-demand create a property-cache for it, and use that later in the object creator. One restriction we add is that the type must not have a dynamic meta-object, given that those don't lend themselves to usable propety caches (given their dynamic nature.) The early check in the property validator is adjusted accordingly. Add a quick test to verify that gadgets continue to work as before. As a drive-by, convert a few repeated QString::arg calls to a single call of the variadic overload. Task-number: QTBUG-122321 Pick-to: 6.7 Change-Id: I860af981250a70f541794b57db3764415ea172f0 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* QtQml: Re-allow assigning of raw numbers to enum property aliasesUlf Hermann2024-02-011-0/+5
| | | | | | | | | | | This used to work and we cannot just take it away. Amends commit 3ea55bf398412d373daab9c92b1498f45de70e96. Pick-to: 6.7 6.6 6.5 6.2 Fixes: QTBUG-121710 Change-Id: I7f856140286bba9d49b7ed1abfdf398a65fb1962 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Use CompiledData::CompilationUnit in more placesUlf Hermann2024-01-201-10/+12
| | | | | | | | | | We rarely actually need the executable CU, and where we need it, we can dynamically create or retrieve it from the engine. To that end, store all the CUs in the same container in the engine. Change-Id: I0b786048c578ac4f41ae4aee601da850fa400f2e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Move property caches into base CUUlf Hermann2024-01-131-3/+4
| | | | | Change-Id: I1567c9d3d61312e98200fb0854d7fcf111983948 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Move BindingPropertyData into the base CUUlf Hermann2024-01-131-2/+2
| | | | | Change-Id: I2edcb2c324919a1131ae490bee9c9b1140097b09 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Move inlineComponentData and icRootName into base CUUlf Hermann2024-01-131-2/+2
| | | | | | Change-Id: I89e44644b083681f069d1d7a385bec68b4bfd80b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Remove QQmlTypeLoader from QQmlImportUlf Hermann2024-01-111-1/+2
| | | | | | | | | The type loader belongs to the engine and we must not store it in engine-independent data structures. We do want the import cache to be stored in the type registry, though (in a separate change). Change-Id: I2828f5098b27bf1fc96852fc2bd160db44b109e7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make builtins an actual moduleUlf Hermann2023-11-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | This way we can eventually use the metatypes generated by the builtins to validate other module using qmltyperegistrar, and throw informed warnings if types are missing. qmltyperegistrar automatically picks up the metatypes of any library linked into a target. This means it always picks up the builtins metatypes now when QtQml is linked in. We now have to check more closely whether an object binding is actually a group property. QVariant now has a value type metaobject and does not pass as "unknown thing" anymore. We also have to move the QML_FOREIGN macros to QQmlIntegration since we want QML_FOREIGN to declare the builtins but we don't want to depend on QtQml. Task-number: QTBUG-101143 Change-Id: I9f1a2713797291b6624aef0ade599d19e0766907 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* qml: replace fromLatin with _L1Anton Kudryavtsev2023-09-151-1/+1
| | | | | | | to improve readability and reduce allocations Change-Id: I1ffe10d6a14fb9cc09dd438cca84f4a1d74b8cb8 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Replace signal name manipulations with QQmlSignalNamesSami Shalayel2023-08-151-1/+2
| | | | | | | | | | | | | | | Remove custom implementations found in qqmljs* and use the static helper methods from qqmlsignalnames_p.h instead. This sometimes requires to move some code around to avoid bugs with property that do not have letters in their name. Add a warning in the JS implementation of the SignalSpy.qml that the used heuristic might fail on certain signal names. Add tests in in tst_qqmllanguage to see if the property change handlers work correctly for weird names. Change-Id: I4dc73c34df7f77f529511fa04ab5fcc5385b59fc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove redundant warningAmanda Hamblin-Trué2023-07-051-13/+0
| | | | | | | | | | | | | | | We already have a generic warning for assigning null to properties that don't support it, so we warn twice. Removed redundant warning so that we only warn once. This partially reverts commit 16aff415a44f5f10c5ac95da72559839305c8ae5. [ChangeLog][QtQml][Important Behavior Changes] Assigning null to a property of incompatible type is now an error instead of a warning. Fixes: QTBUG-102980 Change-Id: I739913ab64628376727b751512717eb4bf7ea5f4 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QML: Use QQmlType as container for composite types (inline or not)Ulf Hermann2023-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives us a unified interface to all kinds of QML types at run time and reduces the effort of finding corresponding type attributes. QQmlType is much larger than CompositeMetaTypeIds. Most composite types, however, are initially referenced by URL, and we call typeForUrl anyway. typeForUrl already creates a mostly functional QQmlType; we only need to add the dynamic metatypes. The same type can be retrieved later and associated with the actual CU using the compositeTypes hash. That way, we don't need any extra type. We do, however, incur the cost of creating the QMetaTypePrivate instances when first referencing a type. This could be optimized, like many things in this area, by using thread safe lazy initialization. Now some QQmlTypes implicitly depend on the CUs they were created for. This creates problems if the CUs are removed but the types still persist. Such a situation can arise if you create and delete engines. In order to avoid it, we: 1. Make the compositeTypes hold a strong reference to the CUs 2. When unlinking, avoid dropping the property caches (as those are used to hold the metaobjects) Now, however we got a cyclic reference between the CU and its QQmlType(s). To resolve this, we clear the QQmlTypes on unlinking. Finally, to avoid deletion recursion when clearing the last CUs on destruction of the QQmlMetaTypeData, we move the compilation units out of the way first. All of this still doesn't work if multiple CUs hold the same QQmlType, since compositeTypes can only hold one CU per type and that may be the one that gets removed first. Therefore, we cannot allow such a situation to happen and have to create a new QQmlType if it arises. It can only arise if you have multiple engines loading the same QML components, which should be fairly rare. For inline components, we apply a similar trick: You can either find an inline component by Url, and receive any type that matches, no matter what CU it belongs to. Or you can request an inline component type that belongs to a specific CU. It turns out we don't have to store the containing type of an IC at all. Also, we slightly change the naming of internal components' "class names" since we want to use the inline components' element names for them. Change-Id: I0ef89bd4b0a02cc927aed2525e72f6bff56df626 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* QML: Register all builtinsUlf Hermann2023-05-221-2/+1
| | | | | | | | | | | | We need run time access to the QQmlType instances of all the builtins in order to properly coerce types without special casing everything all the time. Since we can now have QML types without metaobjects, we need to check for the metaobject in a few places where we didn't need to check before. Change-Id: Ib22cbb12c60ebdce4897c3f3338851e8b925926f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Avoid duplicate value type creationUlf Hermann2023-02-241-3/+3
| | | | | | | | | | | We can actually produce an uninitialized but pre-allocated QVariant using QVariant::Private. Using the new in-place construction support in QMetaObject, we can minimize the amount of copying necessary for value types. Fixes: QTBUG-108789 Change-Id: I6b748794a6adbf6558e1e3086eab80fcfb3154a0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Allow more options for creating value types from JS objectsUlf Hermann2022-09-241-3/+5
| | | | | | | | | | | | | | | | | | | | We allow value types to be created 1. by calling Q_INVOKABLE constructors 2. by setting their values from properties of a JS object Both have to be opted into by setting a class info. If opted into, these options override the existing methods. When a a type can be created by setting its properties, that implies you can also initialize it using an invokable constructor. However, when given a JS object, the properties method is used. We keep this internal and undocumented for now. As the last try (the create(QJSValue) methods and QJSValue ctors) was not that stellar, let's first wait a bit and see if we're getting it right this time around. Fixes: QTBUG-106480 Change-Id: I767230924afcba032d501846cc3263dad57b7bf0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Qml: Drop unused value type provider functionsUlf Hermann2022-09-131-1/+1
| | | | | | | | | The only thing we still need is createValueType(). That is by itself debatable, and it can be static. Change-Id: Id092f547415c600b7d1db01f78661c287e7f4979 Reviewed-by: Semih Yavuz <semih.yavuz@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-111-38/+2
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QML: Port QV4::CompiledData::Binding to new special integer bitfieldUlf Hermann2022-05-111-40/+43
| | | | | | | Pick-to: 5.15 6.2 6.3 Task-number: QTBUG-99545 Change-Id: I9f8bc5fa45c61f77ee95b055a3d8de001da8f8c5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QML: Port QV4::CompiledData::Location to new special integer bitfieldUlf Hermann2022-05-111-2/+4
| | | | | | | | Pick-to: 5.15 6.2 6.3 Task-number: QTBUG-99545 Change-Id: If0d6f893f2351a4146ddf125be4079b5e312f308 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* QML: Port QV4::CompiledData::Object to new special integer bitfieldUlf Hermann2022-05-111-1/+2
| | | | | | | | Pick-to: 5.15 6.2 6.3 Task-number: QTBUG-99545 Change-Id: Ia57a16313e883a8d4dab15c971181440ed1d2214 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* QtQml: Uncruftify QQmlImportsUlf Hermann2022-03-241-3/+6
| | | | | | | | | QQmlImports is a refcounted datastructure. Therefore, use QQmlRefPointer for it, and avoid all the pointless indirection. Also, make the flags type safe and document the mutability of the import namespaces. Change-Id: I54a0db42b2b7cdfb516e9f90c2264edfa800bfe6 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make most QQmlPropertyData constUlf Hermann2022-03-141-4/+4
| | | | | | | You really should not mess with that after creating the property cache. Change-Id: I070200772475bb67f539dbbd85a298020b14ca79 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use const QQmlPropertyCache wherever possibleUlf Hermann2022-03-141-9/+9
| | | | | | | | We're not supposed to modify property caches after they've been created. Task-number: QTBUG-73271 Change-Id: I0ab8ed6750508fa4e28931995142f56cd5fa3061 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QML: Allow named lists of value typesUlf Hermann2022-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We register QList<T> as sequential container type for any value type T we get. This way we can always find a type to use for list<t> with t being a value type. The metatypes are shuffled around so that we have an easier time associating a type with its list and vice versa. As QQmlPropertyData's isQList flag denotes both QQmlListProperty<T> and QList<T> now, we need to use QMetaType::IsQmlList more often. Conversely, any name given to extra sequential containers registered via QML_SEQUENTIAL_CONTAINER is explicitly ignored now. As you can do list<foo> for any type foo now, there is not much of a point in having further named container registrations for the same type. It would just make things more complicated. Mind that the name had already been ignored before, just not explicitly. [ChangeLog][QtQml] You can now use lists of value types in QML. For example a property of type list<int> will hold a list of integers. Task-number: QTBUG-82443 Change-Id: I7bee61cee3963dae5d231bf59f70b8012984371d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Avoid ping-pong between plain pointers and QQmlRefPointerUlf Hermann2022-01-251-1/+1
| | | | | | | | | | | | | | | We want to deal in QQmlRefPointer as much as possible. In particular, assigning nullptr to a QQmlRefPointer triggers the creation of an empty QQmlRefPointer and the assignment of that one. Provide a reset() method to do this in a cleaner way. In turn, make QQmlGuardedContextData::reset() private. It's really dangerous and should not be called from outside. setContextData() is safer but may do additional work. The only place from where reset() was previously called in its public capacity is probably dead code, though. Change-Id: Idb72e255dbfad6e5dd963dc76d719bb9edc10471 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Move propertyCache- and metaObject-related functions into QQmlMetaTypeUlf Hermann2022-01-181-3/+3
| | | | | | | | | | | | That's where the data resides. This allows us to lock the mutex only once for all those methods, and it makes a large number of engine pointers unnecessary. Finally, we can now find the element type of a QQmlListProperty without supplying an engine. Change-Id: If1ae8eafe8762a112d1ca06f9c92ab8a727d1bda Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlEngine: Remove methods that merely forward to QQmlMetaTypeUlf Hermann2022-01-181-1/+1
| | | | | | | There is no reason to drag an engine around for those. Change-Id: I02100b207f197e75dfd458ff1cce5c4920dd94bd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Unify PropertyCache refcountingUlf Hermann2022-01-031-5/+5
| | | | | | | | | We should not keep plain QQmlPropertyCache pointers around. Also optimize self-assignment of QQmlRefPointer. Change-Id: I0e30b4ce29bb6b7acf288a9dc7b515d0e8f4ddfe Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Clean up PropertyCache life cycleUlf Hermann2021-11-091-7/+10
| | | | | | | | | | | | | We generally want to use QQmlRefPointer for it, rather than manually calling addref() and release() all over the place. Also, we can completely inline its ctor and drop an unused member. Also, do not keep property caches of dynamic meta objects in type registry. The dynamic metaobjects will change, and the outdated property caches will eventually be retrieved. Change-Id: I8042c85b32f3031b554f97a35c1545a3412d2acb Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Clean up some includesUlf Hermann2021-11-051-1/+2
| | | | | | | | | We should not include qqmlglobal_p.h just for the export macros as that pulls in a number of other things. Rather, include qtqmlglobal_p.h for that. Change-Id: Iecb60ef676dd880c0d94360ccef6517ef1ec73bf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Allow attached properties in generalized grouped propertiesUlf Hermann2021-11-021-1/+3
| | | | | | | | | | As a side effect this also removes the restriction on attached properties in regular grouped properties. This restriction was an artifact of a past implementation detail. Task-number: QTBUG-95117 Change-Id: I8761e350ed476dc02663b8fb9e1888f0b1392392 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Introduce generalized grouped propertiesUlf Hermann2021-10-281-4/+11
| | | | | | | | | | | | | | | | | | You can now use IDs to set up bindings on other objects than the one currently being constructed. Such bindings are only accepted if the name given as ID is a deferred property in the surrounding object. The best way to achieve this is by giving ImmediatePropertyNames, as that will make all non-immediate names deferred. You are then expected to explicitly handle the resulting deferred bindings, for example in componentComplete(). In order to simply apply the bindings, you can call qmlExecuteDeferred(). Task-number: QTBUG-95117 Change-Id: Iedcf07543426f8f14c23cf53f6f3bcb186a342b0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Pass QMetaType by value rather than by ID in more placesUlf Hermann2021-06-091-14/+15
| | | | | | | | | | This saves us some ping-pong between the IDs and the QMetaTypes, and avoids possible ambiguities if multiple metatypes are registered for the same C++ type. Change-Id: I81cec94a9cd05d69927dc884f65574f0ab2ddc22 Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Allow property observers on readonly propertiesUlf Hermann2021-06-081-2/+4
| | | | | | | | | This makes it necessary to tolerate evaluate() calls after the engine is gone. With non-QProperty properties this can't happen as the engine controls the observers. Change-Id: Ia700a10ad847b8a174b2346a4ad7a4de7afb0c83 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Rename QQmlMetaType::metaObjectForMetaType into metaObjectForValueTypeUlf Hermann2021-06-081-2/+2
| | | | | | | | It really only works for value types and it's not intended to do anythign else. The name should reflect this. Change-Id: Ib73bf7e9655971f7826fe72145e2d2fab363363c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlMetaTypeData: Purge custom string convertersFabian Kosmale2021-03-301-5/+1
| | | | | | | | | Those were never exposed anyway. color, date, etc. are handled by the less generic converters in qqmlstringconverters_p.h. Change-Id: I43a94acda08344de742440dd3b956a7077096b11 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* QQmlMetaType: Remove qmlLists memberFabian Kosmale2021-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a hashmap which maps a QML lists metatype to its list element's metatype, we can just store a pointer in the list metatype to the element metatype. Moreover, listType now returns a metatype. This is a preparation for converting enginePriv->rawMetaObjectForType(typeId) to metaType.metaObject() calls once we can actually retrieve the metaobject from QML metatypes. The QML metatype interface classes are moved into a header, so that Qt for Python can use the same classes. This does not affect types registered from C++, as those use a different mechanism. Task-number: QTBUG-88766 Task-number: QTBUG-82931 Task-number: QTBUG-87134 Change-Id: I330c2bbe4ac92072a333c001750f7504b56df478 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QQmlEnginePrivate: remove functions that only forward to QQmlMetaTypeFabian Kosmale2021-03-051-1/+1
| | | | | | | | | | As a drive-by, remove metatype-id to metatype conversion in qqmlproperty.cpp Task-number: QTBUG-82931 Change-Id: I88511bdc103bfb507b6c4401af103e0aec13894f Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Unregister value types when tearing down QML typesUlf Hermann2021-02-121-5/+5
| | | | | | | | | Move the value type registry into QQmlMetaTypeData. This way we can conveniently drop the relevant entries when unregistering a type. Fixes: QTBUG-86946 Change-Id: Id024a34a8b2b622fd9417fc0e52864b43c66cc01 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Return errors if validation of inline components failsUlf Hermann2021-02-081-1/+3
| | | | | | | Pick-to: 6.0 6.1 Fixes: QTBUG-90038 Change-Id: Ic01b5d097e0b9e6720bcec7ccb18c22abb5418f4 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix IC properties in same fileFabian Kosmale2020-12-101-0/+25
| | | | | | | | | | | Also fixes typename and metatype registration for inline components. Done-with: Fabian Kosmale <fabian.kosmale@qt.io> Pick-to: 5.15 Fixes: QTBUG-89173 Change-Id: I97d65d5539b577a8828d5711e5f2e79c8568b441 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Use QMetaType instead of metatype-id, take 2Fabian Kosmale2020-12-031-5/+5
| | | | | | | | | This time, the ValueTypeFactory gets converted. As a consequence, many callers get touched again. Task-number: QTBUG-88766 Change-Id: I3a8b7d5cfeb7fac85daf1702febba205971d4256 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QML engine: Use QMetaType instead of metatype-id in propertydataFabian Kosmale2020-11-261-20/+20
| | | | | | | | | | | | | | We don't want to convert back and forth between QMetaTypes and ids. This change is the first step towards using QMetaType directly everywhere. By reordering the members of QQmlPropertyData to avoid a gap caused by alignment, we can replace the typeid int with a QMetaType without requiring more space. There are still a few places left using metatype ids, notably the value type logic. Task-number: QTBUG-82931 Change-Id: Ic38f38d10c71ed20655877976c9cb5ee3cbe2d77 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QQmlPropertyValidator: only use string converter for stringsFabian Kosmale2020-10-091-10/+26
| | | | | | | | | | | | | A recent change in fromIsoTimeString exposed the fact that we are using QML's string converters to check whether a binding expression is valid for a given property. However, while we begrudgingly accept that string representations shall be converted to value types via the string converters, the same shouldn't hold true for things that aren't actually strings - for instance, numbers. Fixes: QTBUG-87299 Change-Id: Iefd390efae7c193dc32d37e63943b39e09c9295a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Use factory functions and ctors for creating value typesUlf Hermann2020-10-021-1/+1
| | | | | | | | | | As you can extend value types with QML_EXTENDED we may as well allow a factory function in the extended type. Furthermore, if the original type allows construction from QJSValue, we may just use that. In turn, we can get rid of the value type providers now. Change-Id: I9124ea47537eab6c33d7451080ab2fff942eaa7b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Condense the different value type creation functions into oneUlf Hermann2020-09-231-1/+1
| | | | | | | They all did the same thing. Change-Id: I7661b19ad16c0713d46c4df337899e3897349b2e Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Eliminate QQmlValueTypeProvider::createFromStringUlf Hermann2020-09-231-41/+18
| | | | | | | It can be expressed as a special case of create() with a QJSValue. Change-Id: I7342026ad694077d2780dd8a852714fa72dd68d0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Avoid various warnings about deprected QMetaType methodsUlf Hermann2020-09-161-6/+6
| | | | | Change-Id: I8f4b2703fdd08ff341904219cec33c321e0511c7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make QQmlScriptString an anonymous QML typeUlf Hermann2020-05-181-2/+2
| | | | | | | It needs to be replaced, but we should at least know that it exists. Change-Id: Ia98a9c3b1670f69d34212b904a320617b8c6501d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>