| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Change-Id: I51bb9ca1e8dab6768fc2e85b53a4a6a3aab3a56d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I1567c9d3d61312e98200fb0854d7fcf111983948
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I2edcb2c324919a1131ae490bee9c9b1140097b09
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Change-Id: I89e44644b083681f069d1d7a385bec68b4bfd80b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
to improve readability and reduce allocations
Change-Id: I1ffe10d6a14fb9cc09dd438cca84f4a1d74b8cb8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Pick-to: 5.15 6.2 6.3
Task-number: QTBUG-99545
Change-Id: I9f8bc5fa45c61f77ee95b055a3d8de001da8f8c5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
You really should not mess with that after creating the property cache.
Change-Id: I070200772475bb67f539dbbd85a298020b14ca79
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
There is no reason to drag an engine around for those.
Change-Id: I02100b207f197e75dfd458ff1cce5c4920dd94bd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Pick-to: 6.0 6.1
Fixes: QTBUG-90038
Change-Id: Ic01b5d097e0b9e6720bcec7ccb18c22abb5418f4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
They all did the same thing.
Change-Id: I7661b19ad16c0713d46c4df337899e3897349b2e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
It can be expressed as a special case of create() with a QJSValue.
Change-Id: I7342026ad694077d2780dd8a852714fa72dd68d0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I8f4b2703fdd08ff341904219cec33c321e0511c7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
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>
|