==========================================================
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;
}
DocumentObject:
* getSubObject(): the most important API for Link to work with
hierarchies. The function is a inspired from and replaces the
getPySubObjects(). It returns a child object following a dot separated
subname reference, and can optionally return accumulated
transformation, and/or a python object of the refered
sub-object/element. The default implementation here is to look for
link type property, and search for the referenced object. This patch also
include other specialized implementation of this API, such as
(GeoFeature)GroupExtension (through extensionGetSubObject()),
PartDesign::Body, and so on. A link type object is expected to
call the linked object's getSubObject() for resolving.
* getSubObjectList(): helper function to return a list of object
referenced in the given subname.
* getSubObjects(): return a list of subname references of all children
objects. The purpose of this function is similar to
ViewProvider::claimChildren(). Container type object is expected to
implement this function. The reason it returns subname references
instead of just object is to allow the container to skip hierarchies.
For example, the Assembly3 container uses this to skip the constraint
and element group.
* getLinkedObject(), obtain the linked object, and optionally with the
accumulated transformation. It is expected to return a linked object
or the object itself if it is not a link. In case there are multiple
levels of linking involved, this function allows the caller to retrieve
the linked object recursively.
* hasChildElement(), set/isElementVisible(), controls the children
visibility for a group type object. Because the child object may be
claimed by other objects, it is essential to have independent control
of children visibilities. These APIs are designed to abstract how
group manages the child visibility. For performance reason, these
function are meant to control only the immediate child object.
* resolve(), helper function to parse subname reference and resolve the
final object, and optionally the immediate parent of the final object,
the final object reference name (for calling `set/isElementVisible()`),
and the subname reference if there is one.
* touch(), add optional argument 'noRecompute' for better backward
compatibility with the NoRecompute flag. By default, touch() causes
recompute unless noRecompute is true
* signalChanged/signalBeforeChange, two new signal for tracking changes
of a specific object.
* getViewProviderNameOverride(), return a string of the view provider
type of this object. This allows Python class to override the view
provider of an object. This feature will be used by ViewProviderLink
which is designed to work with any object that has LinkBaseExtension.
* canLinkProperties(), will be used by Gui::PropertyView to display
linked object properties together with the object's own properties.
* redirectSubname(), will be used by Gui::Tree to allow an object to
redirect selection to some other object when (pre)selected in the tree
view.
* Visibility, new property serve as the same purpose as view provider
property of the same name. It is added here so that App namespace
code can check for visibility without Gui module. This is useful,
for example, when constructing a compound shape of a container that
respects the children visibility.
* (has)hasHiddenMarker(), return or check for a special sub-element
name used as marker for overriding sub-object visibility. Will be
used by Gui::ViewProvider, it is put here for the same reason as
adding Visibility property.
* getID(), return object internal identifier. Each object is now
assigned an integer identifier that is unique within its containing
document.
Document:
* ShowHidden, new property to tell tree view whether to show hidden
object items.
* signalTouchedObject, new signal triggered when manually touch an
object when calling its touch() function
* getObjectByID(), get object by its identifier
* addObject() is modified to allow overriding view provider
* has/getLinksTo(), helper function to obtain links to a given object.
Application:
* checkLinkDepth(), helper function to check recursive depth for link
traversal. The depth is checked against the total object count of
all opened documents. The count (_objCount) is internally updated
whenever object is added or removed.
* has/getLinksTo(), same as Document::has/getLinksTo() but return links
from all opened documents.
GroupExtension/OriginGroupExtension/DatumFeature/DatumCS/Part::Feature:
implement sepcialized getSubObject/getSubObjects().
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.
