"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
"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
"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
"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
"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
- Add type check in PropertyCreate to wrap CustomPropertyGroups as a list if not already
- Prevents dropdown from displaying each character of a string as a separate group option
* Gui: Remove references to the Addon Manager if no Std_AddonMgr
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Gui: Switch to disabling controls rather than hiding
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Draft: fix snapper lagging
The `WorkingPlane.get_working_plane()` function is too slow to be called repeatedly by `_get_wp`. That function has been reverted to what it was before #19728.
* Draft: fix snapper lagging
Using WorkingPlane.get_working_plane(update=False) instead of reverting.
* Make prevCursorPosition protected so tools can use it
* DrawSketchHandlerCircle : Position constraint on prevCursorPosition
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Sketcher: improve Make Internals property tooltip
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Sketcher: reword final MakeInternals tooltip
* Sketcher: apply final code review suggestion
Co-authored-by: Max Wilfinger <6246609+maxwxyz@users.noreply.github.com>
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Max Wilfinger <6246609+maxwxyz@users.noreply.github.com>
The standard in FreeCAD is that workbench preference pages get loaded when the module gets loaded.
That behavior was altered by PR 21981 which attempted to load CAM preference pages at startup even if CAM was not loaded.
The result was that pages were only partially loaded and the result was a confusing mess.
There is some discussion about future enhancements to allow workbench preferences to be loaded early.
When that is implemented, CAM will adjust to be compliant with FreeCAD standard.
This effectively revertts PR #21981
