This is a regression caused by PR 17564.
ViewProviderDragger has the member 'forwardedViewProvider' that is used
to handle the editing by the parent object. This means that inside
ViewProviderLink::startEditing 'transformDragger' can be null but this
isn't checked so that accessing the member causes a segmentation fault
or a failing assert in debug mode, respectively.
Solution:
Make sure that transformDragger is not null before accessing it.
This fixes 19542.
The command is only able to show the property view in case it's
invisible. But it fails to raise the widget. And if in the preferences
'Combined' mode is set it fails completely.
Solution:
The method DockWindowManager::activate already does everything what's
needed. Now the command only must be changed to access the right
docked widget.
Introduce a new `ProgressIndicator` base class
(`ProgressIndicator.h`/`.cpp`) with a singleton-managed, no-op default
implementation matching OCCT’s `Message_ProgressIndicator` interface.
Update `CMakeLists.txt` to include the new sources.
Do not use the number of decimals from the user settings to pass
the material to the property as this will cause some unexpected
rounding effects.
This fixes issue 19048
The current implementation always returns a width that is too small
so that a scrollbar is shown. Especially on the General page this is
unfortunate as some important controls are truncated or completely
hidden.
Another problem of this implementation is that when loading a not
yet loaded workbench in the 'Available workbenches' page then the
computed size will be by far too high leading to a dialog that all
the sudden covers most of the screen.
Solution:
The correct width is the sum of:
width of the tree view + width of the biggest page + spacing of the layout
This fixes both of the above problems.
* Fix Workbench::listToolbars() to also return custom toolbars or added by a manipulator
* Fix Workbench::getToolbarItems() to also return custom toolbars or added by a manipulator
* Fix Workbench::listMenus() to also return menus added by a manipulator
Fixes issue 18647
When performing undo/redo after tansforming an object it flips back
to its original position but the dragger does not.
This commit set the dragger's placement to the object placement.
Fixes issue 18914
If the user clicks on undo while the transformation dialog is
open the currently active transaction will be closed.
From now on any change of the placement won't be recorded any
more so that e.g. canceling the dialog or an undo after
accepting the dialog leads to unexpected behaviour.
To fix the issue two new virtual methods onUndo() and onRedo()
are added to TaskDialog and reimplemented in TaskTransformDialog.
These functions make sure to open a new transaction.
This fixes issue 19152
Previously you had to make 4 clicks to apply a combo
1 to enter edit, 1 to open the combo, 1 to select, and 1 to defocus and apply
with this commit only 2 clicks:
1 to open the combo and 1 to select
* Light refactor of getTopoShape function
* Fix hole edge case
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update src/Mod/Part/App/PartFeature.cpp
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
* Update src/Mod/Part/App/PartFeature.cpp
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
* Update src/Mod/Part/App/PartFeature.cpp
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
* Update src/Mod/Part/App/PartFeature.cpp
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
* Refactor simplifyCompound()
* Use Base::Flags<GetShapeOption>
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Shorten enum name and move it from class scope to namespace scope
* [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>
* BIM: Use checkbox in model tree for Activation/Deactivation of WP
* BIM: Set active object after deactivating current object if it exists
Currently we can get into a scenario where user can activate two working
planes, one after another. For example, Level, and then Level001. If
they activate both, and then deactivate Level001, working plane switches
back to Level. But, we didn't set the object as the active one, so user
didn't have clear information that they can deactivate it, only the
working plane was switching it.
So this patch sets the object as the active one, if it exists.
* BIM: Add support for deactivation active object to BIM Views Tree
As the title says - it adds the checkbox that's similarly done in Part
workbench, so user can select/deselect the item and if they had previous
active object, it will also fall back to the previous object.
Also, moved out part of the common logic from ArchBuildingPart and
BimViews to utils.
* BIM: Handle correct context on activating WP for NativeIFC/BIM
* BIM: Remove redundant logic from BIM Views upon double click
As all of the logic is being handled now in `activate` function in
BimViews, this logic is redundant
* BIM: Rename button for taskbar and BIM Views from Activate to Active
* Allow to align the working plane on selected edge + face of a same object, which aligns the plane with the face, but positions it on the edge (the WP is positioned on the edge's first vertex, the WP's X axis is aligned with the edge, and the face's center point provides the third point to define the plane)
* Added a "Recenter" in-command shortcut. This moves the WP to be centered on the current snap position (the WorkingPlane snap button is taken into account, so one can only move the WP in the same plane or not).
