==============================
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.
==================================================================
It is possible to bypass SketchObject in modifying geometry and constraints. Like in here:
https://forum.freecadweb.org/viewtopic.php?f=3&t=41326&start=20#p408409
This leads to unexpected behaviour and even crashes.
With this commit the new mechanism of constraint indices check is leveraged in cases not involving SketchObject operations (aka managed operations).
Direct assignment of properties from Python (sketcher unmanaged operations), undergo this extra indices check.
When indices in constraints are outside the geometry range, the constraints are shown as empty and the error is shown in the report window.
==============================================
Take advantage of PropertyGeometryList setValues() move overload in order to make code more readable and prevent
memory leaks (mostly by inadvertedly not deleting cloned geometry and constraints).
PropertyGeometryList and PropertyConstraintList are vectors of heap allocated pointers. Copying a vector
makes a shallow copy, not a deep copy (the pointers are the same in the copy).
For property management, setValues() function taking a const reference effectively make a deep copy of all
pointed objects. This means that heap allocated pointers of the client class passed to these functions must be
released by the client. While this sounds sensible, forgetting to is easy. In the cases where the developer
remembered to release these pointers, extra code is needed just for memory management.
This commit does not seek a substantial performance increase that would justify rewritting the code, although code
may be slightly faster sometimes.
Functions where setValues() is conditional are not changed to move semantics, as it makes no sense to make a deep copy to sometimes
perform a second deep copy later on. This code still uses const ref setValues().
CHECKS performed to refactored functions with this commit:
1) That the vector is NOT used after moving its content.
2) That whereever there is a clone(), there must be EITHER
-a std::move if using rvalue setValues()
OR
- a delete to free the heap memory after setValues if using the const ref setValues()
3) That memory is released if an exception occurred.
N.B.: A couple of memory leaks are fixed in this commit too.
==============================================================================
Inhibit ViewProviderSketch updateData with invalid data (internal transaction).
Trigger update internally for internal transactions in SketchObject via touched()
so as to trigger updateData.
This leads to a reduction of updateData calls.
===================================================================================
On changing the geometry property (for example from Python), the constraints geometry indices was not rebuild in order to avoid
redundant and unnecessary rebuilds. However, this might cause crashes, as the status of the sketch (or its properties) may be invalid.
It also refactors into OnChanged common functionality.
This commit does NOT solve that the user may be inserting invalid geometry indices to the First/Second/Third of Constraints (invalid input).
Only makes sure that geometry indices (geometry types) of PropertyConstraintList match the geometry.
Solution:
1. Force the rebuild of the constraint geometry indices upon assignment of new Geometry.
2. Force the rebuild of the constraint geometry indices upon assigment of constraints, if they result in invalid geometry indices.
3. Introduce the concept of internal transaction to avoid those rebuilds, checks and updates in case of an ongoing internal transaction,
thereby preventing them as it was done before introducing 1 and 2 (in the case of SketchObject internal transactions).
==================
https://forum.freecadweb.org/viewtopic.php?p=387303#p387303
1. Trim had a bug that the type of the constraint on the second point was equal to the first one regardless of the situation.
2. Trim did not have support for checking whether points were close to the edge and relied on preexisting constraints.
