================================
New deleteGeometries function, according to the comment should the same
as deleteGeometry but at a time. However, this is not accurate, as deleteGeometry
deletes any internal geometry associated to the provided GeoIds, whereas
deleteGeometries does not delete that internal geometry.
Solution:
Split deleteGeometries into two different functions:
1) delGeometriesExclusiveList
2) delGeometry
The former will not delete associated internal geometry. It is more efficient, but
it is the resposibility of the caller not to leave internal geometry undeleted.
The latter, implemented in terms of the former, will delete associated internal
geometry too.
As a bonus, the latter will also remove any GeoId duplicates.
=========================================================================
Sometimes it happens that malformed constraints are arrived to.
Example:
https://forum.freecadweb.org/viewtopic.php?f=3&t=53780#p463271
It is not the first time. They usually go under the radar and when they are
detected is too late to know what caused them. The user is desperate too.
This commit makes malformed constraints to prevent the recompute of the project.
This is in the best interest of the user.
========================================================
This property stores whether a Sketch has 0 DoF or not upon solve.
It is serialised to disk, enabling a recently loaded project to have an accurate
populated property even before the first solve() call.
========================================
Report:
https://github.com/FreeCAD/FreeCAD/pull/4183https://github.com/realthunder/FreeCAD_assembly3/issues/387
Problem:
renameConstraint() previously implemented exclusively in SketchObjectPyImp.cpp,
will change the Constraints property without updating the solver. A prospective
drag operation would rely on a deleted pointer constraint which leads to the
crash.
Solution:
- mark the solver status as needing an update
- leverage new through sketchobject r/w interface to ensure solver is synchronised
before the temporary move operation starts
Bonus:
move the core of the function to SketchObject.cpp so that input data validity
check on constraint change is inhibited.
This fixes issue
https://tracker.freecadweb.org/view.php?id=4513
addSymmetric will now only transfer Vertical and Horizontal constraints if the reference axis is either
- the HAxis
- the VAxis
- a Vertical line
- a Horizontal line
==============================
Do not copy/array internal alignment geometry if the geometry it defines is not part of the operation. Silently ignore it.
If the reference for the operation is one such geometry (or it is the only one), then abort the operation.
================================================================================
Internal Alignment constraint mirroring was never implemented. With the enhancements
brought with implementation of geometry extensions in the sketcher, this lack of
implementation became a crash, as geometry was marked as being internal alignment, while
no associated internal alignment constraint was created.
Restrictions:
- Internal alignment geometry is only to be mirrored if the geometry it defines is also
being mirrored. Internal alignment geometry is otherwise skipped. This is because it
does not make sense to have a pole without a b-spline, or a major axis of a ellipse without
an ellipse.
fixes#4514
==============================================================================
Deletion of a geometry having internal alignment geometry (B-Spline, Ellipse, ...)
involves calling a geometry deletion operation for each internal aligment constraint
in addition to the one of the geometry.
Before this commit, an update call was performed for each of these operations. Now,
there is a single update trigger operation after all the geometries are deleted.
==============================================================================================================
This function is charged with receiving the construction information in a
GeometryMigrationExtension and setting the right data members of SketchGeometryExtension.
=============================================================================================
This commits removes the Geometry construction data member and adapts sketcher code to use
GeometryFacade to access construction information via the SketchGeometryExtension.
========================================================================
Until now BSpline poles were circles relying on physical length units. This lead to several
problems:
- While the BSpline weight follows the circle size, weights do not have length units, but are adimensinal
- As representation of the BSpline depends on the physical size of the circle, the numerical value to be
set to a pole circle differs from the numerical value of the weight.
The present commit:
1. Separates pole circle representation (physical size), from the numerical value used in the radius constraint,
so that the value in the constraint is the weight, the value representation is a factor of the weight value (in this
commit is getScaleFactor(), but this will change in the next commit). Dragging accounts for this scale factor too.
2. While Radius constraint button is used to constraint a B-Spline weight as before, this creates a Weight constraint,
which is a new type of constraint. This is done so that the value is truly adimensional and is so presented in all kind
of editors that rely on the units indicated by the constraint. It is obviously also shown as adimensional (thus without units),
in the 3D view and in the datum dialogs.
3. Because the circle of the pole of a B-Spline is not a geometric circle, but a graphical representation of the pole and how
it affects the corresponding B-Spline, constraint creation commands are limited so that no point on object, tangent, perpendicular
or SnellLaw constraints can be created on a B-Spline weight circle. This is also the case for the Diameter constraint, which won't
accept the circle. Equality constraints work either on only circles or only weights, but not on a mixture of them.
Bonus: This commit fixes a bug in master, that using the select equality constraint then click in two geometric elements mode, you
could make a circle equal to an ellipse resulting in malformed solver constraints.
============================================
This is a new concept which originates from the new ability of sketcher geometry to store a geometry state via
geometry extensions.
The idea is that some geometry state is enforced via constraints (InternalAlignment constraints and Block constraint) which
effectively set the state. However, it is convenient to have direct access of the geometry state from the geometry for representation
(ViewProvider) and for the solver. This is the constraint-driven geometry state concept.
The addition/removal of the constraint defines the life cycle of the geometry state and is responsible for setting and removing
the state, so that geometry state and constraint are kept synchronised.
The life cycle is completed with proper serialisation of the geometry state.
In summary:
1. Upon restore, the stored state is restored and any migration is handled to set the status for legacy files (backwards compatibility)
2. Functionality adding constraints (of the relevant type) calls addGeometryState to set the status
3. Functionality removing constraints (of the relevant type) calls removeGeometryState to remove the status
4. Save mechanism will ensure persistance of the geometry state
===========================================================
The introduction of the ability of the geometry extensions to store information leads opens new
possibilities to the sketcher, which may require migration of previous versions of the sketcher.
A striking example is the migration of the GeomPoint+Construction to mark a B-Spline knot to a proper
geometry state based on the sketch geometr extension.
It also enables to make aware the geometry of the Blocked status, by restoring the geometr blocked
status.
This commit defines an scheleton for this mechanism.
An empty block after a conditional can be a sign of an omission and can decrease maintainability of the code.
Such blocks should contain an explanatory comment to aid future maintainers.
