===========================================================================
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.
=========================================================
fixes#3084fixes#3061 (at least what it is understood in the analysis as being a bug, the visualization left).
Basically when deleting a feature, if it is the base feature (feature with which it will merge or cutout), the dependent objects'
base feature is made to be the base feature of the object being deleted. This code pre-existed at body level, but was not being called (see below).
Additionally, if the visible object is not the one being deleted, we leave that one visible. If the visible object is the one
being deleted, we make the previous object visible.
Deletion from the tree of a feature is handled by Document.removeObject, which has no clue about what a body is. Therefore, Bodies, although an
'activable' container, know nothing about what happens at Document level with the features they contain.
The Deletion command StdCmdDelete::activated, however does notify the viewprovider corresponding to the feature (not body) of the imminent deletion
(before actually doing it). Consequently, the only way of notifying a body of the imminent deletion of one of its features so as to do the clean up
required (moving basefeature references, tip management) is from the viewprovider of the feature being deleted.
Now on property panel there is option 'Coarse View' which allows to set
selected drawing view's Hidden Line Removal to utilize polygonal algorithm.
This should be faster on same cases (complex models).
When this option is set for a view there is known limitation with dimensions not
working on this experimental mode. At least currently this is best utilized on
view with no dimensions.
Also the vertices' 'black dots' are not drawn on this mode view to avoid
cluttering. Face hilite is avoided, to gain speed. All curves are represented
by short linesegments in this mode.
Previously TechDraw always used OCC's exact HLR algorithm to generate views,
which produces good quality and continous shape lines but is sometimes
slower to generate than with polygonal approach.
Additionally now there is bool 'CoarseView' Parameter Editor setting, if anyone
wants to set this as their default.
========================================
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.
