* The Placement of Draft Line base objects was not adjusted to account for the current working plane. Forum topic: https://forum.freecad.org/viewtopic.php?t=86780
* Continue mode checkbox did not behave correctly because its value was based on FreeCADGui.draftToolBar.continueMode, which does not update as the parameter is changed. Will update other Arch code later.
* There was an issue with Draft Line based walls and continue mode. A Draft Line is selected after creation and the next command call would also use that line because of that. Resulting in 2 walls using the same line and an interuption of continue mode.
* setUseSketch changed the wrong parameter.
Provides compatibility loading older files outside the context of
a library.
Older material files were loaded by specifying a path. The new
material system used the path to associated the material with a
library, which may not be appropriate for legacy files. This change
allows the use of materials outside of a library.
Additionally, legacy files often have name/value pairs not part of the
standard list of properties. Since these were unable to be mapped to
a model property they were ignored. Materials now maintain a legacy
map to hold properties not associated with a property model. These
properties are considered transient and will not be saved. It is not
intended for this feature to be used as a generic container for
properties not mapped to an appropriate model.
Fixes#13302
* New integration with 3Dconnexion devices
* CMake build option hidden for Mac
* Minor fixes, to be squashed to previous commit
* cmake: fix indent and case; to be squashed
* Corrected name case
---------
Co-authored-by: Patryk Skowroński <pskowronski@3dconnexion.com>
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
Co-authored-by: Ladislav Michl <ladis@linux-mips.org>
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
