+ improve PropertyMaterialList::readString
+ fix transparency handling in ViewProviderPartExt
+ do not register the private member '_diffuseColor' as property because it would be exposed to the
public where it can be modified
+ fix ViewProviderPartExt::finishRestoring() to correctly restore old project files
+ fix ViewProviderPartExt::setHighlightedFaces() to correctly show face colours if VBO is enabled
+ fix ViewProviderBoolean::updateData()
fix ViewProviderMultiFuse::updateData()
fix ViewProviderMultiCommon::updateData()
fix ViewProviderCompound::updateData()
fix ViewProviderFillet::updateData()
fix ViewProviderChamfer::updateData()
that all set invalid transparency values
+ Filter ShapeAppearance in ViewProviderBody::unifyVisualProperty
because body features usually have different number of faces than the body itself
+ manually fix some bad looking auto-formatted code
+ clean up code and remove duplicated code
Improves the use of the ShapeAppearance property for the Part workbench.
removes DiffuseColor property
adds Python compatibility using custom attributes
transitions DiffuseColor to ShapeAppearance on open
Improved UI elements for setting object appearance, and appearance per face
Lays the foundation for future texture support
* Maybe you meant to call base method instead [-Wclazy-skipped-base-method]
* Missing reference in range-for with non trivial type [-Wclazy-range-loop-reference]
* Mixing iterators with const_iterators [-Wclazy-strict-iterators]
* Unused QByteArray [-Wclazy-unused-non-trivial-variable]
* C++11 range-loop might detach Qt container (QList) [-Wclazy-range-loop-detach]
The Original BaseFeature implementation had some serious issues with scoped links. It failed completely for e.g. sketches on the BaseFeature as it made a local link to refere to a out of body object. The only solution to make this work correctly is to add a proxy object into the body which is alloed to exactly that, to link outside oof the body. Something like shapebinder.
==================================================================
The problem:
OriginGroupExtension::OriginGroupExtension () {
initExtensionType(OriginGroupExtension::getExtensionClassTypeId());
EXTENSION_ADD_PROPERTY_TYPE ( Origin, (0), 0, App::Prop_Hidden, "Origin linked to the group" );
}
initializes the Origin property to null.
Then Document::Restore => readObjects => addObject => slotNewObject => ViewProviderDocumentObject::updateView => ViewProviderBody::updateData => ViewProviderGeometryObject::updateData =>
ViewProviderDocumentObject::updateData => ViewProvider::updateData => ViewProviderOriginGroupExtension::extensionUpdateData => updateOriginSize() => OriginGroupExtension::getOrigin,
the latter throws an exception because the origin property is null.
Afterwards, the origin property is initialized during Document::Restore => readObjects => ExtensionContainer::Restore() => PropertyContainer::Restore() => App::PropertyLink::Restore()
=> App::PropertyLink::setValue() => Property::hasSetValue, which triggers an onChange: Body::onChanged => BodyBase::onChanged => Feature::onChanged => DocumentObject::onChanged =>
Document::onChangedProperty => Document::slotChangedObject => ViewProviderOriginGroupExtension::slotChangedObjectGui => ViewProviderOriginGroupExtension::updateOriginSize =>
OriginGroupExtension::getOrigin,
now, the latter that is the same that was throwing the exception and generating the error message above, does not throw anymore because Origin has been initialized.
When creating a new object, isNew==true; whereas when loading a file, isNew==false. Therefore, when loading a file setupObject is not executed. SetupObject, effectively initializes
the extension via: Body::setupObject => DocumentObject::setupObject => OriginGroupExtension::onExtendedSetupObject.
DocumentObject * Document::addObject(const char* sType, const char* pObjectName, bool isNew)
{
[more code here]
// Call the object-specific initialization
if (!d->undoing && !d->rollback && isNew) {
pcObject->setupObject ();
}
[more code here]
As DocumentObject code is generic for all objects (workbenches), by design it was chosen to initialize the object only if new. Therefore a object or an extension of a object being restored,
between the addition (addObject) and the restoring of the properties, must by design expect it not to be initialized.
The solution:
Making use of the Restore flag at document level (the one at object level is not sufficient), no exception regarding the null property is reported during document restoring.
Ticket:
https://freecadweb.org/tracker/view.php?id=2530fixes#2530
