- add preview/live update to TaskSectionView & TaskComplexSection
- add view direction selector to uis
- use SectionNormal as Direction. Make Direction read-only
- simplify section line end point calculation
- section group command in toolbar
- make section and complex section icons consistent
- fix compsolid cutting tool
- terminology: single/piecewise to offset/aligned
- as discussed in https://github.com/FreeCAD/FreeCAD/pull/7642 the backwards compatibility for deprecated holes was already lost since FC 0.19
- this PR removes the deprecated types and transform holes created with FC 0.19 or 0.20 to the corresponding countersinks/counterbores.
- also add Counterdrill for translations
The problem is that inside Transaction::addObjectNew() a transaction object is deleted before removing it from the container. When deleting the corresponding transactional object (i.e. a DocumentObject or ViewProvider)
it can happen that it e.g. calls Transaction::addOrRemoveProperty() that now finds the dangling pointer in the container.
The safe way is to first remove the object from the container before deleting it.
The counterbore is basically a special case of the countersink
with a countersink angle of 180 degrees and applied depth.
Handling it that way elimintaes some duplicate code and adds the ability to
combine countersinks and counterbore to form a counterdrill.
The sanity check on countersinkAngle can be safely dropped as it is ensured
by a constraint on the property itself.
HoleCutDepth is reset to 0 to force a recalculation of te depth when
HoleCutType is set to a new value.
But the line
pcHole->HoleCutCustomValues.setValue(false)
also forces a recalculation. So the depth was recalculated with the old
value in HoleCutType which was not expected behaviour.
================================================================
Master has a problem in that internal alignment constraints are suggested to the user for removal.
This is fundamentally wrong, as an internal alignment constraint are an inherent part of the geometry. They cannot be the ones suggested for removal.
The popularity contest algorithm is an heuristic algorithm that determines which redundant/conflicting constraints should be proposed for removal.
Basically, the algorithm works on groups of redundant/conflicting constraints detected via the QR decomposition. A constraint may belong to more than one group.
The algorithm runs some heuristics, each constraint scoring a value, the one constraint from each group scoring the highest is proposed (is more popular and wins the contest).
This PR documents the algorithm, and adds a further condition, that internal alignment constraints are never proposed.
As the solver works with solver constraints as opposed to the sketcher, which works with sketcher constraints, information about whether a solver constraint originated from a
sketcher constraint that is internal alignment is necessary. So the solver constraint is extended to accomodate this piece of information.
As a bonus, it fixes a bug. Solver constraints carry information of the ID of the corresponding sketcher constraint in their tag. Knots are not currently implemented as constraints.
However, the tag index was not being update. This caused the popularity contest to provide wrong suggestions despite good detection.
