Fixes#23900.
The ShapeAppearance related code should be removed. It is atypical that the result of a boolean operation has the same number of faces as one of its source objects, therefore simply applying its ShapeAppearance to the new object does not make sense in most cases.
The ShapeAppearance of Fusion objects gets overwritten by other code. For Cut objects this does not happen anymore (Used to happen in V0.21).
* Assembly: Simulation: Fix motion double click
* [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>
"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
"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
Fix base template substitution and improve tool/op formatting in sanity report, also update HTML/CSS and image handling.
- Major HTML/CSS refactor for CAM Sanity Report template:
- Rewrote HTMLTemplate.py with modern, responsive CSS, semantic HTML, and accessibility improvements.
- Added CSS reset, responsive image handling, and improved table/list styling.
- Introduced .heading-container and .top-link for right-aligned "Top" navigation links on all major sections and tool headers (hidden in print).
- Updated all section and tool headers to use new navigation and layout.
- Cleaned up legacy markup, removed inline styles, and standardized variable substitution using string.Template syntax (${key}, ${val}).
- Updated base_template in HTMLTemplate.py to use string.Template syntax (${key}, ${val}) instead of %{key}, %{val} for correct variable substitution.
- Enhanced image generation and embedding:
- Updated ImageBuilder to support high-DPI (800x800) images and direct byte output for embedding.
- All report images (base, stock, datum, tool) now use in-memory bytes for embedding when possible.
- Tool images support a toggle for using toolbit thumbnails or fallback head-on renders.
- ReportGenerator now embeds images as base64 when requested, with correct HTML tags.
- Improved squawk, tool, and operation data formatting:
- Squawk dates now use localized string formatting.
- Tool diameter and feedrate now use .UserString for better display.
- Spindle speed now formatted as integer with "rpm" suffix.
- Operation feed and speed values also use .UserString and "rpm" formatting.
- Fixed _format_bases in ReportGenerator.py to iterate over base_data.items() and pass {"key": key, "val": val} to the template, ensuring all bases are listed correctly.
- General code cleanup and improved maintainability throughout the CAM Sanity reporting stack.
- 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.
