The Materials module does a conversion from float to double when saving the transparency and again a conversion from double to float to double
when restoring it. This causes a considerable loss of accuracy so that the representation in percent leads to different numbers.
Using consistently some helper functions to do a proper conversion from float to long and back fixes the problem.
The new property ShapeAppearance is a PropertyMaterialList and always read after the DiffuseColor property when restoring a document.
Thus, the method onChanged() doesn't override DiffuseColor when restoring a document. Additionally, the method finishRestoring() is re-implemented
to set the colours per face in case DiffuseColor has defined multiple colors.
When synchronizing the Transparency property with the transparency value of the ShapeAppearance property then do not convert between float and
double as otherwise some strange rounding issues can occur.
Example: Set the Transparency property of an object to 35 in the Property Editor. After leaving the editor the value may switch to 34.
* Correctly load a file if colors are set per face
* Result of boolean operation is correctly colored if source objects have different colors
* Result of compound is correctly colored if source objects have different colors
* fix several linter warnings
* remove code that cannot be executed: inside the constructor it cannot ever happen that getObject()
returns a valid object
* in ViewProviderGeometryObject::handleChangedPropertyName call the method of the direct base class
as otherwise this may break the mechanism in the future
* Shape is a property of an extension module -> move its handling to ViewProviderPartExt
This PR demonstrates the known regressions of the recently merged material branch:
* Changing the transparency after setting color per face will reset them
* The result of boolean operations or compound doesn't inherit the colour of its input objects
* If colour is set per face to a boolean operaton object then saving and restoring the file causes weird rendering behaviour
because material binding is set to PER_PART but only a single colour is defined
* If a shape inside a part container has set colour per face then saving and restoring as STEP file causes weird rendering
behaviour for the same reason
* Shape binder or datum objects don't show the correct default shape colour
* Fixed translations
* Reference objects can now use whole file contents instead of having to choose a part
* Support for DXF files
* Support for IFC files (if NativeIFC is available)
* General code cleanup
