With PR 19114 the commands to create PD datum objects are replaced with
the counterparts of Part. However, PD datum objects are much more powerful
than the Part datum objects.
(see e.g. https://forum.freecad.org/viewtopic.php?p=806960)
So, this change brings these commands back to the task panel.
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
Every time the InvoluteGearFeature python module was imported, and we're
in GUI context, the command "PartDesign_InvoluteGear" was registered. On
the 2nd (3rd, ...) time, this was reported as an error in the console,
like "error: Command.cpp(1841): duplicate command PartDesign_InvoluteGear"
The first import happens when the PartDesign FreeCAD Module is loaded,
via `InitGui.py`. Subsequent imports may happen when e.g. executing the
involute gear command or when running it's tests via FC's Test WB.
This change now registers the command only then the PartDesign WB is set
up in InitGui, not when importing the python module. The same fix is
applied for sprocket, where the same pattern for command registration
was used.
In addition, the import error catch was removed, which seems to be a copy
paste left-over from the ShaftWizard. In contrast to ShaftWizard,
involute gear and sprocket only use modules from the Python standard lib,
so I think this precaution is not worth the additional complexity, just
for hiding actual errors.
Dialogs to view the Appearance and Material properties of an object
These inspectors are intended to be used when debugging Appearance and
Material issues in a model.
The Appearance inspector displays the appearance properties of an
object. This will be more useful once PR 13792 is merged which migrates
parts to use ShapeAppearance instead of DiffuseColor. This shows each
of the appearance properties per face for the object.
The Material inspector shows the material, models, and properties
assigned to a model. It displays useful debugging information such as
the UUID and file paths associated with eacch of the items. This is
useful when finding and resolving model conflicts.
The material inspector now gives the option of copying the information
to the clipboard.
Uses new material system for appearance
Each feature object now has a property called ShapeMaterial that
describes its physical properties. If it has a shape, it has a
material.
The ShapeColor attribute is replaced by a ShapeAppearance attribute.
This is a material list that describes all appearance properties, not
just diffuse color. As a list in can be used for all elements of a
shape, such as edges and faces.
A new widget is provided to allow the user to select materials in a
consistent fashion. It can also launch the material editor with its
more advanced capabilities.
