Pool QML items
I am stuck at creating an object pool of QML items:
As the creation of my QML items takes quite long, I would like to create them in advance and avoid destroying and recreating them with component.createObject(), but use a pool of items instead and setting visible to false for "logically removed" items.
So my first question is, if there is an easy way to store the initial state of an item and all of its child components, so save the initial state of all its (non-function- and non-object-type) properties?
I tried to iterate over all properties of all items and child items and store the property values in a variant. This works fine, but the problem with that approach is that properties that were assigned with a property binding (e.g. property2: property1+5) would be overwritten at initialization, and the property binding is lost! From what I have seen in C++ code, QDeclarativePropertyPrivate contains information about the used binding type (PropertyBinding or ValueTypeProxy declared in QDeclarativeBinding which is also private), but as it is private I cant access it from C++ nor QML.
Any ideas how to find out if a property was defined by a binding, or is there another approach I could use?
one solution could be using the State object, an 'initial' or 'not initial', then the binding and all values will then be conditional to the state.
It seems simple so you have probably already think at it, but i didn't see any other way
I'm wondering why the binding type of a property is not available as public information - any ideas of an approach I might use?
I found a solution that is a little bit hacky, but it works:
QDeclarativeProperty declarativeProperty(object, propertyName);
QDeclarativeAbstractBinding *abstractBinding = QDeclarativePropertyPrivate::binding(declarativeProperty);
// if abstractBinding is not null, the property was defined as a binding and thus should not get overwritten
So it is only doable in C++, and you also need to include private header files qdeclarativeproperty_p.h and qdeclarativebinding_p.h, which depend internally on many other private header files of QDeclarative module and 1 header from QScript module. I could not find another approach without having to include them.
Any odds against this approach?