=================================================
With the support for external geometry during carbon copy, it was introduced a way for creating inter-part/inter-body links. See:
https://forum.freecadweb.org/viewtopic.php?f=10&t=27700&p=223736#p223736
This commit closes this door, while still allows carbon copy with external geometry support within the same body.
=======================================================
set/get/toggle python interface to enable to set the virtual space status of a constraint via SketchObject.
=====================================================================
The constraint class has been extended so that every constraint knows and serializes whether it is in virtual space or in normal real space.
===========================================================================
Block constraint is naturally redundant/conflicting with almost any other constraint applied to an edge (certainly with constraints operating only on that element).
As such, a block constraint will have very little applicability in absence of a way to handle this redundancy/conflicting. For example, in the case of a BSpline all its
internal geometry (construction circles on poles and its constraints) would have to be removed before locking. This would mean that it is not possible to define the BSpline shape
and then block it, as when removing the internal geometry the shape would be lost. In other cases, like temporally blocking to avoid that a part of the sketch moves while performing some
operation with the idea of afterwards unblocking it, it would mean removing all constraints, to add the block constraint, then perform the action, then remove the block constraint and manually
constraint it again.
Handling this situation in a user expected way means ignoring certain constraints (those causing the redundancy/conflicting), so that the solver is not aware of them and does not complain. However,
generally ignoring those constraints has a negative effect, in that constraints applied by the user on already blocked geometry, or constraints that otherwise lead to a conflicting or redundant
situation as a consequence of actions (further constraining) after the Block constrain is applied are ignored, thereby not properly informing the user of this situation, which is undesirable.
This new mechanism takes account on the position of the constraints relative to the involved blocked constraint(s). As such, redundant/conflicting constraints that were added before the Block
constraint are ignored, whereas those constraints that lead to a redundant/conflicting situation and added AFTER the block constraint was already in place, those are not ignored and are reported
accordingly.
========================================
When writting solver implementations it has to be taken into account that the normal is not to be provided in the sense of the curvature, but to
the left when walking a curve from start to end.
https://forum.freecadweb.org/viewtopic.php?f=10&t=26312#p209486
This commit has impact on all the previous files using bspline and endpoint to endpoint tangency.
A work-around is to delete the tangency and do it again.
================================================================================
When transfering constraints to coincident points on deletion of geometry, a tangency/perpendicular constraint
cannot be blindly transfered as the destination edge may not be tangent/perpendicular leading to unexpected behaviour.
However, the user does expect that something that was coincident with such end-to-endpoint constraint (which implicitly includes a coincident constraint)
remains coincident after deletion. Therefore, the change of type to coincident.
This implicitly solves the problem of representation of constraints leading to a crash in coin3d.
fixes#3291
=============================================================
Just amazed it was working "so well" without never reseting to zero this.
It might bring advantages and close bugs... who knows!
===========================================================================
Cleaning up ViewProviderSketch, as relative mode is never used for points.
Adapting the recalculation of the initial solution only to non-relative cases.
For relative movement cases (movePoint with relative=true) no cases where such a solution will be advantageous have been identified
and applying a similar solution involves changing the current behaviour too much, as to run the risk of introducing further bugs.
Decision to be revised if such cases where an advantage can be found are discovered.
=====================================================================
fixes#1734
Upon dragging, the initial solution is first calculated and them DogLeg is left with the work of solving for a solution next to the initial solution.
When the change is too big and the gradients are no longer accurate to continue dragging, the dragging flips and jumps.
The solution offered here is, not to update always the solution, as this also creates artifacts, but update it if the dragging goes beyond 20 times the initial dragging distance.
https://forum.freecadweb.org/viewtopic.php?f=3&t=7589#p203580https://forum.freecadweb.org/viewtopic.php?f=3&t=7589#p203712
