==========================================================
Currently changes of name or type of properties in a property container are handled by:
void PropertyContainer::handleChangedPropertyName(Base::XMLReader &reader, const char * TypeName, const char *PropName)
void PropertyContainer::changedPropertyType(Base::XMLReader &reader, const char * TypeName, Property * prop)
There is no mechanism for handling property changes by extensions. Sometimes the solution is to explicitly call the extension
from the container. However, this is a breach of the SRP, as the container should not be in a position to decide whether the
extension needs or not handle property changes. The handling code of the container changes for two different reasons, for
adapting the container to a property change of its own, and for adapting that of a property of the extension.
Illustrating it with an example, following inheritance, it goes like this:
PropertyContainer => ExtensionContainer => TransactionalObject => ViewProvider
App::Extension => ViewProviderExtension
The extension is currently not notified by the ExtensionContainer that a property needs handling. So a change in a property of
a ViewProviderExtension needs code at the ViewProvider it was added to.
This commit provides a mechanism in ExtensionContainer to call the extensions so that they can handle property changes. This
functions:
virtual bool extensionHandleChangedPropertyName(Base::XMLReader &reader, const char * TypeName, const char *PropName);
virtual bool extensionHandleChangedPropertyType(Base::XMLReader &reader, const char * TypeName, Property * prop);
Containers should always call the base class for any unhandled property change. If a sub-class container of ExtensionContainer
handles property changes itself, but not the ones of the extensions, this call to the base class ultimately ensures that if the
property was not handled by the container hierarchy, any extension is given an opportunity to handle it.
Some examples:
* A container handles the extension property change or its own:
void ContainerSubClass::handleChangedPropertyType(...)
{
if (prop == &PropertyOfExt) {
}
else if (prop == &PropertyOfCont) {
}
else {
ContainerBaseClass::handleChangedPropertyType(...);
}
}
* A container and the extension handle their own:
void ContainerSubClass::handleChangedPropertyType(...)
{
if (prop == &PropertyOfCont) {
}
else {
// This will call ExtensionContainer::handleChangedPropertyType
ContainerBaseClass::handleChangedPropertyType(...);
}
}
bool ExtensionSubClass::extensionHandleChangedPropertyType(...)
{
if (prop == &PropertyOfCont) {
return true;
}
return false;
}
* Part: fix Placement/Shape onChanged() handling
* App: fix property ordering problem when undo/redo
See https://tracker.freecadweb.org/view.php?id=4265#c14271
* Gui: fix undo/redo signaling
Make sure to signal after all properties has been restored
No longer add dynamic property for alias, simply rely on
get(Dynamic)PropertyByName() to check for aliases.
Add new API PropertyContainer::getPropertyNamedList() so that
ExpressionCompleter can discover properties with aliases.
Property:
* Extended property status bitset. Mirror most of PropertyType and
allow dynamic change property type.
* Cache property name and type to improve performance
* Centralize property status change signalling
* Change aboutToSetValue()/hasSetValue() to virtual
* Add new API getFullName() to obtain full quanlified name of the property
AtomicPropertyChangeInterface:
* Allow calling aboutToSetValue()/hasSetValue() when actually changed
PropertyLists:
* Refactor implementation by an abstract class PropertyListBase and a
template class PropertyListsT, to allow better code reuse.
PropertyListT is derived from AtomicPropertyChangeInterface to allow
more efficient change on individual elements.
* All list type property now accept setting python value as a dictionary
with index as key to set individual element of a list.
* Add touch list for more efficient handling of value changes. The list
contains the index of changed value. And empty touch list should be
treated as the entire list is changed. PropertyContainerPy expose this
functionality with getPropertyTouchList().
PropertyPersistentObject:
* New property to allow dynamic creation of any FreeCAD object derived
from Base::Persistence, and use it as a property.
DynamicProperty:
* Use boost multi_index_container for efficient property lookup while
keeping order.
* Modify to be allowed to use in PropertyContainer directly
PropertyContainer:
* Use boost multi_index_container for efficient property lookup while
keeping order.
* Allow adding/removing dynamic property on all property container
* Modify Save/Restore() to persist property status, and better handle
transient property which can now be dynamically enabled/disabled per
object.
* Add new API getFullName() to obtain full quanlified name of the property.
Implemented by Document, DocumentObject, and also
ViewProviderDocumentObject if future patch
DocumentObject and FeaturePython are modified to accommondate the
dynamic property changes.
Removed get/setCustomAttribute() implementation from DocumentObjectPy,
and rely on PropertyContainerPy for the implementation, because of the
additional dynamic property support in property container.
Gui::ViewProviderDocumentObject, which is derived from
PropertyContainer, is also modified accordingly
At the moment many feature classes lack of the mustExecute() method and thus can cause a touched feature not to be recomputed and causes the feature to be in a broken state.
Now this new enum value virtually makes the mustExecute() superfluous and thus guarantees to recompute a feature if a modified property has not set the Prop_NoRecompute flag.
On the other hand there are properties that should only touch a feature but not enforce a recompute. This guarantees a better performance and avoids unnecessary recomputes.
For example this is useful for placements where a change can be applied on-the-fly and the feature is up-to-date. Other features that depend on the touched feature will still be recomputed.
PropertyContainer uses a static member of type PropertyData to register
static properties. PropertyData uses a short variable to record the
offset of the property against its container.
Because of possible 'short' truncation, when searching of property that
in fact is from another container, we must check if the pointer within
boundary. Otherwise, truncation will result in effectively random
number, and possibly causing a false hit.
Due to problems onthe windows platform the virtual inheritance approach must be dropped. NExt to the already reimplemented proeprty interface the Type interface is reimplemented too. This change allows to revert some earlier changes.
FreeCADs property system utilises some pointer math to calculate the offset between
property and base class. Due to virtual inheritance of th ePropertyContainer the memory
layout has been changed to rather random, which has lead to crashes dependend on the
order of object initialisation.
The solution is to not make PropertyContaner virtual but a class below, Base::Persitance.
Then the memory layout is random for Persistance, but it is perfectly aligned for the
base class chains from PropertyContainer onwards as well as from Extension onwards.
Hence the proeprty system was changed to take the offset always from those two.
