When a profile-based beam had its Base property cleared and the model
was recomputed, the beam would rotate 90 degrees, changing its direction
completely.
Profile objects are always created in the XY plane with Width along X,
height along Y and normal along Z. However, if Base is cleared, fallback
code always used YZ plane orientation for beams. This resulted in a
different orientation during cleaned Base property.
Fix is to check if we are profile-based or not and if yes, use XY plane
orientation, while we don't have this property then just use YZ plane
orientation (preserving traditional horizontal behavior).
* Assembly: Fix Iisolate issue when obj and link both in assembly
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update src/Mod/Assembly/Gui/ViewProviderAssembly.cpp
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
* [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>
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
* Sketcher: Do not open command if one is pending in doSetVisible
* [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>
Currently `removeSplitter()` function attempts to merge coplanar faces
by using `ModelRefine::FaceUniter`, which internally uses
`BRepBuilderAPI_Sewing`. This can fail in several scenarios, like
inability to produce a valid shell, failing in face unification due
to geometry incompatibilities, or when we have tolerance issue in the
reconstructed geometry from glTF triangulation that prevent us from face
merging.
That leads to the exception, which we are not handling correctly where
it's being handled the same way as this patch introduces in other parts
of FreeCAD.
So, this patch adds a try-catch block around `removeSplitter()` to
gracefully handle `Standard_Failure` exception and return the sewn shape
instead of crashing. Imported model will contain more individual faces
than necessary (since coplanar won't be merged), resulting in a more
complex topology in the places of those fails, but geometry and visual
appearance will be preserved.
* BIM: Implement double-click event for materials group
Add double-click handling for materials group in Tree View.
Fixes: https://github.com/FreeCAD/FreeCAD/issues/24766
* [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: Fix issue of reversed arcs input for polar pattern
* DrawSketchHandlerRotate: remove getRotatedPoint that is no longer needed
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update Geometry.cpp
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* [PartDesign] create a new Gui Unit Test for the creation of a sketch and...
...improve the Selection Filter syntax error to show where it's being generated from.
* [PartDesign] address Lint feedback
* PD/Tests: Ensure test file does not exist before SaveAs
---------
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
ArchMaterial's view provider has a setTaskValue helper to set values of widgets inside a task panel. While specific to ArchMaterial, the real place where the helper is called is at BIM_Classification. It appears it's not a general but more like an ad-hoc API for a specific purpose and for a specific object.
In any case, this fix allows widgets that expect a numerical value to have their value set. Before, their value was set as text, unexpectedly.
Before this fix, double-clicking on an ArchMultimaterial object opened its task panel as expected. Unexpectedly, its label was selected and set for edit.
- The tree view's double-click handling expects the view-provider to declare whether it handled the double-click.
- The ViewProvider API's doubleClicked() is documented to return bool (True if handled).
- If a view provider's doubleClicked method returns None/False, the tree falls back to the default Qt behavior (which is beginning inline editing of the item label).
- In ArchMaterial.py the view provider calls self.edit() (or FreeCADGui.ActiveDocument.setEdit(...)) but the method that the tree actually calls (the view provider's doubleClicked) does not return True. Because the method returns None, the tree continues and starts inline label-editing.
In summary: setEdit returning True is fine, but doubleClicked is the method the tree checks; it must return True to suppress the default inline rename.
