================================================================================================================
std:async can take two policies one that forces the task to be run in parallel another (deferred) that runs the task
when wait is called on the future (kind of lazy evaluation).
Default policy is let the system decide (an or of both policies). Nobody is a better position than the system to know
its load and whether it is possible to run the task in parallel or not.
If the system cannot allocate a thread and parallel processing is enforced (as before this commit), then it will throw an
exception. In the present case we would catch it and run the task sequencially. Thus, it makes sense to let the system
decide from the beginning and save the exception and the handling.
In tests I have only managed to see it run in parallel with the default policy.
=================================================================
Diagnose constraints do not include among others driven constraints. This
function allows to know whether the solver is considering an empty matrix.
=================================================================================
Some geometry extensions do not provide a PyObject as they do not have a Python counterpart
as it would serve no purpose to have it.
This commit handles this situation making sure to provide the right error to Python
or to ignore the extension where appropriate.
==============================================================================
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.
===================================================
Currently the ID is a unique number without an specific use and it is
conceived to be taken over by future RT's Sketcher PRs.
Because of this, and not to interfere with RT's implementation, it is
not stored, but will be restored if attribute available.
Unrelated:
Similarly, ExternalGeometryExtension is also there conceived for RT's
future sketcher PRs, but it is not used.
==================================================================
GeometryExtension was originally designed to be serializable (save/restore). However,
GeometryMigrationExtension and ViewProviderSketchGeometryExtension have demonstrated the
usefulness of runtime-only GeometryExtensions.
The problem with runtime-only extensions being of a serializable type (GeometryExtension before
this commit) arises when Part::Geometry is to serialize the extensions and serialise the number
of extensions the geometry has. If runtime-only GeometryExtensions do not save a tag, then the
restore mechanism will expect more extensions that are actually in the XML file.
This commit makes GeometryExtension by default not serializable and deriving directly from
Base::BaseClass. A new class GeometryPersistentExtension is created, deriving from GeometryExtension
to provide serialisation. All Extensions requiring serialization derive from GeometryPersistentExtension
and those not requiring it from GeometryExtension directly.
This commit adapts all extensions to the new situation:
Part: GeometryDefaultExtension
Part: GeometryMigrationExtension
Sketcher: ViewProvierSketchGeometryExtension
Sketcher: SketchGeometryExtension and ExternalGeometryExtension
==============================================================================================================
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.
========================================================================================================
Access to the Construction state from facade is now obtained from the extension data.
================================================================================
First step towards migration - Create Construction Geometry Mode in Extension
============================================
A new enum to remove magic numbers for constraint tags.
A previous version of the commit introduced more magic numbers, which
demonstrated not to be up for the task.
About the Tag numbers:
- Positive Tags identify a higher level constraint form which the solver constraint originates
- Negative Tags represent temporary constraints, used for example in moving operations, these
have a different handling in component splitting, see GCS::initSolution. Lifetime is defined by
the container object via GCS::clearByTag
- Hardcoded value -1 is used for these constraints.The effect is parameters are not truly enforced
(it gives a nice effect when dragging the edge of an unconstrained circle, that the center won't
move if the edge can be dragged, and only when/if the edge cannot be dragged, e.g. radius constraint,
the center is moved).
==========================================================
Previously for Weights, ViewProviderSketch used getScaleFactor. This caused that upon zoom change
the Weights would not increase progresively, rather the would grow on the next redraw. Additionally,
upon substantial zoom out, the poles would grow several times bigger than the B-Spline.
This commit uses a new geometry extension intended only for ViewProviderSketch, to store a geometry
specific representation scale factor. This is calculated as a function of the B-Spline length. The
extension does not serialise to disk. It is just intended for runtime.
Dragging from the edge when the radius is constrained gives a wrong cosmetic result, because the representation circle and the
real value of the weight are different (by a scale factor). This commit prevents dragging on the edge in the most representative
cases where the radius is constrained.
========================================================================
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
========================================================================================
Until this commit, B-Spline knots were stored, and checked at solver level as sketch points GeomPoints having the
construction status set to true.
This behaviour is removed to eventually enable normal non-construction points to define the shape out of edit mode.
This commit leverages the new mechanism for the solver interface.
===========================================================
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.
