When a property value changes, first update all dependent bindings to
their new value. Only once that is done send out all the notifications
and changed signals.
This way, if a property depends on multiple other properties, which all
get changed, there will only be one notification; and (potentially
invalid) intermediate values will not be observed.
Fixes: QTBUG-89844
Change-Id: I086077934aee6dc940705f08a87bf8448708881f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Too much of the existing code in Qt requires eager evaluation without
large scale modifications. Combined with the fact that supporting both
eager and lazy evaluation has a high maintenance burden, keeping lazy
evaluation, at least in its current state, is not worth it.
This does not diminish other benefits of the new property system, which
include
- a C++ API to setup and modify bindings and
- faster execution compared to QML's existing bindings and the ability
to use them without having a QML engine.
We do no longer benefit from doing less work thanks to laziness. A later
commit will introduce grouping support to recapture some of this
benefit.
[ChangeLog][Import Behavior Change][QProperty] QProperty uses always
eager evaluation now when a dependency in a binding changes.
Change-Id: I34694fd5c7bcb1d31a0052d2e3da8b68d016671b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
A few methods in QBindable which do not modify anything were not marked
as const so far. This adds the missing const, and a test to verify that
they work.
As all methods are fully inline, this does not cause any binary
compatibility issues.
Fixes: QTBUG-89508
Change-Id: If06d33bc405232887b8c371c268840ba34dbadf6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This commit amends 4ceaf22bed.
Signal parameter was not actually used, even is the signal was
specified.
This patch fixes it and also introduces unit-tests for this issue.
Change-Id: I029d413644eb6a72af3bdce27cc5f5bcadfe946a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There is no need to write emit and notify at the same time, as not
emitting after notify does not make sense.
This naturally only applies to properties with a changed signal.
Change-Id: I99ff7863a509262ad9d4f7c9c5afbc66fd37001c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
For QObjectCompatProperty, which allows to do basically anything in its
setter, it is actually easier to manually specify when the change should
become visible. This is in line with manually writing emit calls in the
old property system, and allows the preservation of class invariants.
Change-Id: I585bd3f25d722ca3fd721ead85fe73dbee26c5f6
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Introduction of QObjectCompatProperty requires every write to
the property to be examined whether it is OK or should be replaced
by a setValueBypassingBindings/markDirty combination. The existence
of operator= make this difficult as it is easy to miss places where
it is written. By not having operator=, we can help developers
make sure they had a conscious decision about each write to the
property.
Change-Id: Ia61ea4722eb0bab26ce7684b85dd03d710cd1751
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is in line with QML where
import QtQuick 2.15
Rectangle {
width: 100
height: 100
color: "red"
Rectangle {
id: inner
x: 10
y: x
width: 50
height: 50
onYChanged: { console.log("hey"); inner.x = 10}
TapHandler {
onTapped: inner.x = 20
}
}
}
results in a binding loop warning when the tap handler triggers. While
the change handler would only run once, we cannot statically determine
if we need to loop once, twice, or if there actually is a diverging
loop. Thus we unconditionally warn about the binding loop and stop
executing the binding.
As a drive-by, verify in the related test that a change handler which
overwrites its properties binding itself removes the binding.
Change-Id: I5372019c2389ab724c49cd7489ecbd3ebced1c69
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We missed takeBinding as a supported operation on Q(Untyped)Bindable.
To avoid adding version checks to code dealing with QBindableInterface,
we simply synthesize takeBinding as a combination of binding to retrieve
the binding and setBinding with a default-constructed
QUntypedPropertyBinding.
Change-Id: I43803a0dfe210353d0235f0373d2257f75ffe534
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
To optimize certain operations, it can be useful to know whether we are
currently evaluating a binding. For instance, we have properties whose
storage is only alloctaed on-demand when they are set. However, we would
also allocate them if they are used in a binding context, as we would
otherwise not properly track the dependency. Using
isAnyBindingEvaluating in the getter, we can detect this
situation, and avoid the allocation if it returns false.
This API is private for now, as it exposes some internals of the
property system and should be used with care. As it needs to access the
TLS variable, it also has a non-negligible cost.
Change-Id: I373aabee644fe7020b2ffba7d6a0ad9a1e1b4ec0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If we create a QBindable from a const property, we should obtain a
read-only interface. Besides implementing this feature, this patch adds
a isReadOnly method to Q(Untyped)Bindable which can be used to check
whether one can modify the property via the bindable interface.
Task-number: QTBUG-89505
Task-number: QTBUG-89469
Change-Id: Ic36949a5b84c5119e0060ed0a1cf4ac94a66f341
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This adds functionality for marking properties (QProperty and related
classes) manually as dirty. This facilliates the integration of bindable
properties with non-binable properties and makes it possible for
bindable properties to change due to external events.
Fixes: QTBUG-89167
Change-Id: I256cf154d914149dacb6cadaba92b13c88c9d027
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When an eager binding triggers a setBinding call, we end up with a
special kind of binding loop:
setBinding() -> evaluate -> notifyObserver
^ |
| /
----------------------------
We now catch set condition, and set the binding status to BindingLoop
(with a distinct description).
Task-number: QTBUG-87153
Task-number: QTBUG-87733
Pick-to: 6.0
Change-Id: I9f9915797d82eab820fc279baceaf89d7e5a3f4a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The intention was always that you can define properties that do
not require a changed signal. But having to explicitly pass
a nullptr as signal parameter into the macro is ugly, so
use the cool QT_OVERLOADED_MACRO to make it optional.
Pick-to: 6.0
Change-Id: I0ce366d043850f983c968d73c544d89933c48df9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If a QBindable is created from a computed property, it is not possible
to actually set a value or a binding. If we try to do it anyway, we'd
get a crash. Thus we now check whether the function pointer is null
before invoking it.
Pick-to: 6.0
Task-number: QTBUG-87153
Change-Id: I5bedb9080ccf79d9b8166b80d5733d095ed76f8d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Avoid spurious bindings by resetting the binding state before calling
the setter of eager properties.
Fixes: QTBUG-88999
Pick-to: 6.0
Change-Id: I1e3b5662307d906598335a21d306be9c606529d4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This ensurse that we do not do dobule notifications in setValue.
Moerover we avoid needless notifications in markDirtyAndNotifyObservers
when the value did not change. Lastly, if the value did actually change,
we pass that information along to notify, so that we do not evaluate the
eager property twice.
Fixes a test-case which errorneously relied on the old behavior, and
adds a new test which verifies that the fix works.
Change-Id: I8ec6fa2fe8611565dfc603ceab3ba5f92999b26c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
std::function as a type is rather unfortunate for us, as its SSO buffer
makes it rather large, and we can ensure that the function is never
empty.
Considering that we do need to allocate memory for
QPropertyBindingPrivate anyway, we can get rid of the SSO buffer and
instead coalesce the allocations (similar to how std::make_shared works).
The memory looks then like
[--QPropertyBindingPrivate--][Functor]
and QPropertyBindingPrivate can get a pointer to the functor via
reinterpret_cast<std::byte>(this)+sizeof(QPropertyBindingPrivate).
To actually do anything with the functor, we do however need a "vtable"
which describes how we can call, destroy and move the functor. This is
done by creating a constexpr struct of function pointers, and storing a
pointer to it in QPropertyBindingPrivate.
As a consequence of those changes, we cannot use QESDP anymore, as we
now have to carefully deallocate the buffer we used for both the
QPropertyBindingPrivate and the functor. We introduce a custom
refcounting pointer for that. While we're at it, we make the refcount
non-atomic, as bindings do not work across threads to begin with.
Moreover, we can now make the class non-virtual, as that was only needed
to hack around limitations of QESDP in the context of exported symbols.
Change-Id: Idc5507e4c120e28df5bd5aea717fe69f15e540dc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This simplifies code that would otherwise need to use the setter and
getter in addition to the bindable.
Change-Id: Iec6510b4f578f5b223c63b3a0719257a0cf2463d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
As propertyobservers can execute arbitrarily complex code, they can also
modify the obsever list in multiple ways. To protect against list
corruption resulting from this, we introduce a protection scheme which
makes the list resilient against modification.
A detailed description of the scheme can be found as a comment in
QPropertyObserverPointer::notify.
Task-number: QTBUG-87153
Change-Id: I9bb49e457165ddc1e4c8bbdf3d3c9fbf5ff27e94
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
ChangeHandler's evaluated the binding to detect if the value actually
changed. This is a valid strategy for lazy bindings, but eager bindings
were already evaluated at that point, and thus the change would not be
detected.
Change the binding loop test, so that there isn't a fixpoint in the
binding loop, and we can still detect it. Changing the binding loop
detection code to deal with this case is left as an exercise for the
future.
Change-Id: Ia5d9ce2cd98a5780e69c993b5824024eb186c154
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The semantics are not very intuitive, and it opens a can of worms
with regards to what should happen with observers that observe
that property.
Change-Id: I6fb00b7693904b968224cc87d098bbd0ea776ba3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
In the internal hash map implementation, we have to ensure that the
index is in the interval [0, size - 1].
Moreover, in setBinding we have to refetch the binding storage in case a
reallocation happened.
Change-Id: I11c6264f16537699c8908b647e2355a39ce87648
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Before we had the option of eager evaluation, we were able to use the
dirty flag to detect whether we are recursing. However, eager properties
will lead to a evaluateIfDirtyAndReturnTrueIfValueChanged call, and that
in turn will clear the dirty flag.
Introduce a new member to detect that situation, and set the bindings
error state to BindingLoop if we detect that kind of loop.
Change-Id: If40b93221848bd9e9422502318d992fad95b0b74
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
So far QPropertyAlias was limited to working with QProperty<T>.
Change the implementation, so it can be constructed from any
property or even a QBindable<T>.
Change-Id: I175cffe94a9ef332367d39faa976eb065b0e6ffe
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add a new BINDABLE declaration to the Q_PROPERTY() macro that tells moc
where to find the QBindable for the property.
Add a QUntypedBindable base class to QBindable<T> that gives access to
generic functionality and checks argument compatibility at runtime.
QBindable<T> will still do static checking at compile time.
Add QMetaProperty::isBindable() and QMetaProperty::bindable()
to be able to dynamically access the binding functionality.
Change-Id: Ic7b08ae2cde83fd43e627d813a886e1de01fa3dc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add a compatibility property class that makes porting to the new
property system as simple as possible.
Binding evaluation for those compat properties is eager, as we
do not control possible side effects of the code in the existing
setters.
Change-Id: Ic56347abb49e40631ec73e88c6d40d4bdb05ca29
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add a QObjectComputedProperty. This class doesn't store the data
itself, instead relies on a getter method to compute it's value.
As the property is read-only, one can not bind to it, but it can
be used in other property bindings.
Change-Id: I0f6bffdd9f80f1d0829826f93a47257f2b3127af
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add Q_OBJECT_BINDABLE_PROPERTY() macro that can be used to define
a bindable property inside QObject.
The macro and the class behind it creates storage for a property
that is bindable inside a QObject or QObjectPrivate. The property
only uses as much space as the data contained, ie. it has no
storage overhead, as long as no bindings are being used.
Bindings are being stored and looked up in the QBindingStorage
associated with the owning object.
Change-Id: I1dadd7bddbad6fbf10cfa791d6461574b9db82dd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Add a private QBindableInterface and a public QBindable<T>
class, that will be the API interface for accessing bindings
for properties in QObject.
The QBindable class gives access to all aspects of
the property related to bindings. This includes setting
and retrieving bindings, installing observers and creating
a direct binding on this property.
Change-Id: Iaead54d2bd6947bd2cda5052142b2a47dd8bf7c4
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
These look rather weird, an explicit property.setBinding() call
is simply better in this case, and also more aligned with the API
we can offer in QObject.
Change-Id: Ifb00fd47a75e6b3bc94e34bf49e4f13249565bfe
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
And all related functionality. This is being replaced by
Q_BINDABLE_PROPERTY and Q_OBJECT_BINDABLE_PROPERTY in the
next few commits. The new infrastructure coming will play
nicer along with the existing property system.
Commented out some autotests, that will get reimplemented
with the updated infrastructure.
Change-Id: I50c30bd4d5c6c6b6471f8eb93870e27d86f5a009
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Rename QPropertyBase to QPropertyBindingData, as it contains the
data related to bindings. The new name fits better, as the data
can now also live somewhere else than the data strored in the
property.
Change-Id: I489efb86ad2e0bad2740c9d1aa74506fe103d343
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Since we will be storing property data differently in most cases,
having this special case would create too many additional complications.
Change-Id: I27042b0730559bb375d8e3c07324398403a9885d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Enable the arrow operator for all types that could have members, so
that one can e.g. write myStringProperty->size() instead of having to
use the less convenient myStringProperty.value().size().
Also cleaned up the rvalue ref overloads to be
disabled for basic types. For those we now also
return by value, for more complex types we
return a const reference.
Change-Id: If6a75898dc0a097f57052488f0af0cd7166b3393
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We can end up in a situation where a (soon to be destroyed) observer is
owned by a binding which is about to be deleted. If in that situation
the binding is destroyed first, we end up with a dangling pointer
and ensuing memory corruption. Instead, we now first transfer the
ownership of the observer and only destroy the binding afterwards.
Fixes: QTBUG-85824
Change-Id: I721c0319281ada981ae7896bd2e02e9a0cc901b8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
For types that don't have an operator==(), always trigger the binding
and the changed notification.
Task-number: QTBUG-85578
Change-Id: I41374f6d13c88106f4de83864e82172f3a248150
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
And mark some methods as inline.
Performance is critical for our new property system. Compiling
it in one unit makes it possible for the compiler to do a much
better job at inlining and generating optimized code.
Improves performance of binding evaluations by another 20%.
Change-Id: I5a2aa93c74d2b68418b0a9d2e34d8199bb71e3ad
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Avoid any QVariant or type dependent code in the cpp files.
Instead, let the binding wrapper determine if the value
has changed and return true/false accordingly.
This required also some reworking of the guard mechanism
for notified properties, where the guard function wrapper
now calls first the binding evaluation function and then
passes the result to the guard.
Change-Id: I350d07a508ccc0c5db7054a0efa4f270b6a78ec3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There's no point in returning a usually empty error when
evaluating bindings, adding overhead to the regular code
path.
Instead, the error can be set on the currently evaluating
binding if required. This streamlines the functor used to
wrap the binding and should thus expand to less code and
execute faster in the regular case.
To achieve this, expose a pointer to the currently evaluating
binding in the private API (as QtQml needs it to be able to
report errors).
The error case now requires one additional TLS lookup, but
we don't really care about performance in that case anyway.
Change-Id: Iecb450e765244930a41d813fcf8eb4013957a6a3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Remove location(). The method would always return an empty value. If you need the location,
the binding itself has it.
Remove setDescription() and require that the description gets passed
in the constructor. Never create a d pointer if type is NoError, so we
can quickly check for it inline.
Change-Id: I7eb8a94786281069d6ea2d82567c09aa50c52ef6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Adding support for a static notifier within QProperty itself - through a
QProperty "sister" class - is more efficient in terms of memory
consumption and run-time performance.
The MemberChangeHandler permanently takes up at least three pointers,
while the notified properties only cost one pointer in the binding.
Change-Id: Ia1a8c2b66f1f3c2fe13ae0ad9f12cdb6bdcc35ef
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
A guard callback is a predicate which takes the new value set by
setValue or computed as the result of a binding expression. If it
returns false, the value is discarded and the old value is kept.
Note that due to lazyness, when setting a binding, we still notify
everyone as the binding is only evaluated on demand, and the guard can
thus only run when someone actually queries the value.
Note further that a guard is allowed to modify the value that is passed
to it (e.g. to clamp it to a certain range).
Task-number: QTBUG-85032
Change-Id: I3551e4357fe5780fb75da80bf8be208ec152dc2a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Check at compile time whether the static callback takes an argument
(which has to be of the same time as the type of the property). If so,
retrieve the old value and pass it to the callback.
Change-Id: Ib1c4c9e05b826b6be492b03f66fa72ad015963ee
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The static observer can live in a union with the inline observers. We
only need to take care of calling the ctors and dtors manually then.
In order for any observers to be called in the presence of a static
observer, the static observer has to be called after the other
observers.
Change-Id: I2f56fa64f3fe6fcd7f06cc403929362da7d86f65
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
