* [Core] Add Boolean Functions to expressions (AND, OR, BOOL, NOT)
* [Core] Add `if` function to expressions to overcome ternary operator limitations
* [Core] Update expressions grammar to recognize relational operations as arguments
* [Core] The `if` function has been removed as no consensus was reached regarding its convenience or necessity. Its inclusion was considered potentially confusing or redundant.
* [Core] Make boolean cast based on Confusion threshold.
* Ensure the ::Remove flag of DocumentObject is set to true before calls to breakLinks
* TechDraw: remove then add balloon annotation when changing the SourceView
* Revert "TechDraw: remove then add balloon annotation when changing the SourceView"
This reverts commit 483b4fe4a0715ff63c2669af33fc3beb60a93f54.
* Concatenate all of Document::addObject[s] functions into calls to Document::_addObject
* Fix minor logic errors
* use ::isPerformingTransaction instead of direct operators
* Uniform case for enum
* Remove dupplicate code for Document::removeObject
* Use CamelCase for enum and fix comment
Dimensionless quantities have all exponents equal to zero.
Such quantities are simply numbers. The associated unit is
the unit one, symbol 1, although this is rarely explicitly
written.
See chapter 2.3.3 Dimensions of quantities, The International
System of Units, 9th edition.
Quantity is often queried for Unit just to see if it has a dimension.
Ask Quantity directly using isDimensionless() method and modify that
method not to care about Quantity value validity; no user was ever
asking for value validity.
Introduce a `Build(const Message_ProgressRange&)` overload in
`FCBRepAlgoAPI_BooleanOperation` (guarded by `OCC_VERSION_HEX <
0x070600`) and route user-abort checks around the operation. Add a new
`OCCTProgressIndicator` adapter (`OCCTProgressIndicator.h`) that bridges
`Message_ProgressIndicator` to `Base::ProgressIndicator`. Include
`OCCTProgressIndicator.h` where needed and update all `Build()` calls in
`TopoShape` and `TopoShapeExpansion` to pass
`OCCTProgressIndicator().Start()`, enabling singleton-based progress
reporting and user-break handling.
* [Start] ensure user's preferred unit schema is retained after restart of application
* [App] use consistent schema names throughout the application
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* [Start] Revert commit 2eea421
in preference to PR #21466
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
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.
