Traditionally when calling reserve it's because you expect to append
up to X amount of bytes. We should keep that behavior the same.
With another patch still in the works current behavior caused an issue
with QStringBuilder in QNAM, as mirrored in the testcase attached.
Change-Id: I9792a8f158fc9235e3de48ac8b06ac2c10e7f3dc
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Views / delegates absolutely *adore* hammering data(). A simple
QListView showing a couple of dozens entries can call data()
a hundred of times on the first show.
Back of the hand calculation,
* 2 times per visible item (sizeHint() + paint()),
* times 9 roles used by the default delegate,
* times 20 visible items
= 360 as a bare minimum, assuming the view doesn't redraw twice
accidentally. Move the mouse over the view, and that'll cause
a full update with certain styles: 360 calls to data() per update.
This has an overhead visible in profilers. The model's data()
has to re-fetch the index from its data structure and extract
the requested field every time.
Also, QVariant is used for the data interexchange,
meaning anything that won't fit in one is also a memory allocation.
This problem will likely be gone in Qt6Variant as that
will store sizeof(void*) * 3, meaning QImage/QPixmap and similar
polymorphic classes will fit in a QVariant now...
So I'm trying to to remove part of that overhead by allowing
views to request all the data they need in one go. For now,
one index a a time.
A view might also store the data returned. The idea is that
the same role on different indexes will _very likely_
return variants of the same type. So a model could move-assign
the data into the variant, avoiding the memory allocation
/deallocation for the variant's private.
This patch:
1) Introduces QModelRoleData as a holder for role+data.
2) Introduces QModelRoleDataSpan as a span over QModelRoleData.
The idea of a span type is twofold. First and foremost, we are
in no position to choose which kind of container a view should
use to store the QModelRoleData objects for a multiData() call;
a span abstracts any contiguous sequence, leaving the view free
to do whatever it wants (statically allocate, use a vector, etc.).
It also solves the problem of efficient passing the roles and
gathering the returned variants from multiData().
3) Add multiData(), which populates a span of roles for a given
model index. The main advantage here is that a model can fetch
all the needed information for a given index just once, then
iterate on the span and provide data for each requested role.
Cf. this with data(), where every call has to re-fetch
the information for the index.
A couple of models have been ported to multiData(), as well as
QStyledItemDelegate.
[ChangeLog][QtCore][QModelRoleData] New class.
[ChangeLog][QtCore][QModelRoleDataSpan] New class.
[ChangeLog][QtCore][QAbstractItemModel] Added the multiData()
function.
Change-Id: Icce0d108ad4e156c9fb05c83ce6df5f58f99f118
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When the view was already sorted by the column and order given to
sortByColumn(), a resort was not triggered which is a regression since
d0f909f8db.
Therefore don't rely on sortIndicatorChanged() in this case and trigger
an explicit sort as it's done when no user-triggered sorting is enabled
Fixes: QTBUG-86268
Change-Id: I3ec30ab81f304d5a19cef6d67b8a81c21b4a112d
Pick-to: 5.15
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Fix a warning about truncating a const through a static_cast
on MSVC.
Change-Id: I381ce806d602c006ef6f14eb4fc89716bc5403ae
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
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>
This is required to properly implement QPropertyAlias on
all properties.
Change-Id: I2443b52aa72116596fa0891e5f8b8414518dcd93
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>
Make it possible to evaluate the binding but write the result into
a different memory location. This will help support compat properties,
where the setter does a lot of additional work.
Change-Id: Ib60220eb629e3dcb5c0d7004b693e92290dfabe5
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>
This should always work to allow clearing a binding.
Change-Id: I55165a50f7fe62a1f8a5078d452968db09a6d360
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Simplify the data structure. We only need one pointer for either
the static callback or a bindingWrapper, so don't share it
with the dependency observer array.
Also ensure we reset the propertyDataPtr and clear the observers
when the binding gets removed from a property.
Change-Id: I4c1e7ec7823c3ef12c63d6f758b757e7bac60cae
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QBindingStorage is a class that can store a set of binding objects
for the properties of a QObject. This will get used to reduce the
memory overhead of the property system when adding bindable properties
to QObject based classes.
The binding storage has a pointer to the TLS entry containing the
currently evaluating binding. Like that we avoid repeated TLS
lookups and reduce the overhead of the property system to one
pointer lookup and one compare for the case that properties
aren't being used.
Each QObject now owns one binding storage object, that can be used to
store binding data for properties that members of the QObject.
Change-Id: I27427c03c2ba281f072e074be96147bdbcaac246
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
Reorder source code to make the follow-up work easier. Also clean up
retrieving the pointer to the aliased property.
Make setSource(QPropertyBindingData) public, it'll be needed later on.
Change-Id: I784fdceac8722c7df756b2d7c35e08c7ab3a2074
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Add an empty QUntypedPropertyData class. This allows making
a couple of places where the system is currently using a
void * more type safe.
Also add a QPropertyData<T> as an intermediate class between
QUntypedPropertyData and QProperty. This class will get used
in a future commit to simplify storing property data separately
from the possible binding data.
Also simplify the static observer handling a bit by always
passing it a pointer to the QUntypedPropertyData instead of
some other void * that could point to anything.
Change-Id: I1f8144ea717815b1bc6f034d1ac883c13af5aaf8
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>
The r-value setBinding() overloads can be removed,
as they took a copy internally anyway.
Change-Id: I691265299e5cb336791f614b30788c81467df534
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Generalize some methods taking a QProperty<T>,
so that they can work with other types that
implement the QProperty interface as well.
This removes some duplication between QProperty and
QNotifiedProperty. It also makes it possible to
create private property classes that store their
data in a different place.
Change-Id: I4b1ae8589cb9a76be59e63206044dcf2244163c2
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Do not unnecessarily downscale the pixmap; QIcon will set the correct
device pixel ratio.
Pick-to: 5.15
Task-number: QTBUG-86344
Change-Id: I04ba93ec3003d3dfd458b032cc5c8fc9cf38e957
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Use a float device pixel ratio in the style animations and default
to the application's device pixel ratio.
Pick-to: 5.15
Task-number: QTBUG-86344
Change-Id: I093bfefc0f544eb488da0993a183f92c9c77a286
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Amends fe4794f70e
Depending on the types, the generic QTest::toString version might be
used, which returns nullptr.
Change-Id: Ic60675057181629d1cf9cb22e7508d57c026a0ad
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
QT_DEVICE_PIXEL_RATIO is replaced by QT_SCALE_FACTOR, while
QT_AUTO_SCREEN_SCALE_FACTOR is replaced by QT_ENABLE_HIGHDPI_SCALING.
Since High-DPI is now always enabled, there's no reason to keep the
code path for android.app.auto_screen_scale_factor. Also, based on
the original commit message that introduced this code, the value of
the property should have been true.
Change-Id: Ib34b1deeab46c488c67c4d64f087599b4a54dc55
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
They are actually equivalent, but from different enums.
Change-Id: Ic5f148e2e6bb260c226026b3f89333626a6020ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
As the private headers are not included by default in the precompiled
header QDoc builds for QtGui, create a custom module header for
the documentation build and pull in the required headers.
Add dummy declarations for Windows-specific types for building docs
on non-Windows platforms.
Task-number: QTBUG-83252
Change-Id: I225ed08f68cf4f7c1f1d093424070b13ce36aa51
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Exclude the default value (-1) from the check.
Amends 0bd770fb87.
Pick-to: 5.12 5.15 5.15.1
Change-Id: Ib98ae166fd5fdab546c5d4212ce78345b5c9b583
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If one needed to listen to a signal just once, one had to
store the QMetaObject::Connection object returned by connect()
and use it to disconnect the slot after the first signal
activation.
This has led to a proliferation of using wrappers (and enough
TMP); they usually look like this:
1) create a shared_ptr<QMO::Connection>, allocating its payload;
2) create a lambda, capturing the shared_ptr by value;
3) in the lambda, disconnect the connection (through the shared_ptr),
and call the actual slot;
4) connect the signal to the lambda, storing the returned
QMO::Connection into the shared_ptr.
This is expensive, error prone for newcomers, and tricky to
support as a general facility inside one's projects.
We can do better, just support single shot connections right
in QObject.
[ChangeLog][QtCore][QObject] Added the Qt::SingleShotConnection
flag. When a connection is established with this flag set,
the slot is going to be activated at most once; when the signal
is emitted, the connection gets automatically broken by Qt.
Change-Id: I5f5feeae7f76c9c3d6323d841efba81c8f98ce7e
Fixes: QTBUG-44219
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
QEvent::Pointer will probably end up unused in Qt 6, but removing it
right now would break qtdeclarative; this might continue for a little
while longer.
Change-Id: I02c4901068be710ffd31261b306e1b8ec1988c63
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
One could guess it by assuming that disconnecting for a destroyed
receiver and disconnect() with given receiver use the same
implementation, but without closely knowing the implementation a
reader of the documentation can't know for sure.
Also add a test to prove that what the new documentation says is
really true.
Also remove an unnecessary negation in the preceding sentence.
Change-Id: I9d24442bb1a4646b89f969bad1a4d0e1eafa7534
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is in line with QMetaType and will be used to implement a mutable
QSequentialIterable. Later on, a QMetaAssociation will be added as
well, to implement a mutable QAssociativeIterable.
The code here represents the minimal set of functionality needed to have
a practical sequential container. The functionality is not completely
orthogonal. In particular, the index based operations could be
implemented in terms of iterator-based operations.
Task-number: QTBUG-81716
Change-Id: Ibd41eb7db248a774673c701549d9a03cbf2e48b6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Change-Id: I82d3ddd4a9129694d6dedcc742165cb2af135527
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
We never passed a valid target name to qt_apply_rpaths.
This amends fde98f7794.
Task-number: QTBUG-85399
Change-Id: I1c023ce30a3a8b5ec43d020373960d19fe20f59a
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
With the Qt6 compatibility break, it can finally be removed.
Closing windows (which might quit the application with
quitOnLastWindowClosed() true, the default) acted contrary to the
documentation of the commitDataRequest() signal, which could have
been a hint.
This removes the workaround API from the fix for QTBUG-49667 and
also removes the problematic feature that it worked around.
Change-Id: I672be58864ef062df7fb7f2a81658b92c4feedd2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
