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.
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
Historically, `App::Document::recompute()` ran entirely on the **main**
(GUI) thread and directly emitted `signalBeforeRecompute()`.
* Add-ons like **Assembly3** and others depend on that signal for
setup/teardown hooks before any recompute work begins.
* After offloading `recompute()` into a background worker thread to keep
the UI responsive, calling `signalBeforeRecompute()` directly from the
worker would break thread-affinity rules and silently break
compatibility with those add-ons.
**Solution**
1. **Introduce a generic hook** (`PreRecomputeHook`) in
**App::Document**:
* A `std::function<void()>` that, if set, is invoked at the very
start of `recompute()`.
* Core code stays Qt-free—only knows to call a callback if one
exists.
2. **Wire up the hook in `Gui::Document`**:
* In the GUI wrapper’s constructor, install a hook that calls
`callSignalBeforeRecompute()`.
* `callSignalBeforeRecompute()` uses `QMetaObject::invokeMethod(...,
Qt::BlockingQueuedConnection)` to enqueue `signalBeforeRecompute()` on
the GUI thread and **block** the worker until it completes.
* If already on the GUI thread, it simply calls the signal directly.
3. **Maintain add-on compatibility**:
* From the add-on’s perspective nothing changes—they still receive
`signalBeforeRecompute()` on the main thread before any recompute work.
* Internally, the recompute body now runs on a worker thread,
improving UI responsiveness without breaking existing hooks.
**Result**
* **Recompute** remains fully backward-compatible for add-ons like
Assembly3.
* **UI thread** still handles all GUI-related signaling.
* **Worker thread** performs the actual heavy lifting, unblocked only
once the GUI is primed and all pre-recompute signals have been
delivered.
This function dates back to Qt3, and was removed in Qt4. Modern Qt no
longer uses this ui file entry, and in some circumstances the uic
complains about its presence.
Our GUI code uses a mix of floats and doubles to represent floating
point numbers, and in a few places interchanges them in a way that
causes an invisible loss of precision. Change the double precision
"default" values to float defaults, and use the appropriate value for
pi.
There are multiple possible conversion paths for a QPixmap to QVariant,
which results in a compiler warning. Explicitly specify the path we
intend to silence the warning.
`std::shared_ptr` default-initializes to `nullptr`, so there is no need
to do it manually, and in the current code the initialization is in the
wrong order (so generates a compiler warning).
Fix warning: suggest braces around empty body in an ‘if’ statement.
While there also guard similar debug messages instead of commenting
them out.
Fixes: 8d2cb99712 ("Gui: Added classic trackball orbit style")
