For some reason the empty layout was not saved for users with existing
config. To ensure that the change does not affect existing users and is
persistent for current ones we need to save value with older default
before using it. Previous solution did not work correctly as the widgets
were not persisted correctly.
Prevent crash (CAMTests) in ToolBitRecomputeObserver when the toolbit object has been deleted/missing
by catching ReferenceError before accessing its Document attribute. This ensures slotRecomputedDocument
exits gracefully if the object is no longer valid.
src/Mod/CAM/Path/Tool/toolbit/models/base.py
- Wrapped access to self.toolbit_proxy.obj.Document in try/except to handle ReferenceError
if object is deleted/missing, preventing crash during document recompute.
This basically is due to how OverlayTabWidget::setRect is implemented. If it faces width (or
height) of 0 it forces the width to be minimumOverlayWidth * 3, which in the default config
appears to be 90. 90 is obviously way too small of a value to display any widget in the side
panel, so we need to basically need to treat anything smaller or equal to that as an
incorrect value for width. We use here 100 just to be safe.
For the height value of 100 may be reasonable, so we leave it as is.
Introduced FLOAT_EPSILON for robust floating point comparisons, resolving cases
where Z axis retract moves were missing after geometry recompute in 3D Surface
rotational scan operations. This prevents precision errors from causing the
cutter to skip intended lifts between rings or scan lines.
src/Mod/CAM/Path/Op/Surface.py
- Added FLOAT_EPSILON constant
- Updated Z move comparison logic to use tolerance
A bug in the ToolBit model caused an infinite recompute loop and UI freeze when properties such as Diameter, Flutes, or CuttingEdgeHeight were set to expressions. The visual representation update was being triggered during document recompute, which could recursively trigger further recomputes. This fix defers visual updates by queuing them and processing only after the document recompute completes, using a document observer. The observer is cleaned up after use and on object deletion, preventing memory leaks and repeated recompute cycles.
src/Mod/CAM/Path/Tool/toolbit/models/base.py:
- ToolBitRecomputeObserver: Document observer class that triggers queued visual updates after recompute completes via slotRecomputedDocument.
- _queue_visual_update: Queues a visual update to be processed after document recompute.
- _setup_recompute_observer: Registers the document observer for recompute completion.
- _process_queued_visual_update: Processes the queued visual update and cleans up the observer.
- onChanged: Now queues visual updates instead of calling them directly.
- onDelete: Cleans up any pending document observer before object removal.
This change tries to detect invalid state where overlay was
half-initialized that resulted in overlay being enabled for more users
that we initially aimed for.
* Connect Bool checkbox checkStateChanged to the editor callback so changes will actually happen.
Make the change compatible with Qt versions <6.7.0
* Remove delayed singleshot-value changed from the event filter for Checkbox as suggested by @pieterhijma
* Remove no longer relevent comment
When a geometry element is selected and then hidden using the visibility
checkbox in the Elements panel, it remains in the selection.
Subsequently, if another geometry element is selected and deleted, both
the visible element AND the hidden element are deleted.
Root cause of that is basically that `changeLayer()` functions change
the geometry's visual layer, but never clear the geometry from
`Gui::Selection()`.
So, this patch adds the handling to collect every sub-element name of
the hidden geometry and then formats it and calls remove selection on
the geometry during layer change transaction.
* [ArchStairs] Fix StringerOverlap Base at Angle
Github Issue Discussion
- https://github.com/FreeCAD/FreeCAD/issues/24321#issuecomment-3492459309
"... error when Stringer Overlap is set above certain threshold combined with a non-baseless stair which does not have orthogonal direction - this means that the base line or sketch is rotated to a degree, which is not 0, 90, 180 or 270 degrees."
Further
Fix#24321
* [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>
Fixes#25084.
Instead of a brep file a point list is now used to generate the figure.
Additionally:
Two points have been added to make the head of the figure less 'pointy'.
It would make sense to move the `get_human_figure` function to a different file in the future.
With 1.7m the figure is not very tall BTW.
