==================================================================
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.
===========================================================================
The aim is to easily differentiate a circle that is a normal circle from a circle that is internal geometry, no matter
if the normal circle is construction or not.
The underlying reason is that next commits will introduce a different treatment for internal geometry circles being B-Spline
poles, to which a new constraint Weight instead of a normal radius constraint will be applied, even though the representation
continues to be as circles.
============================================
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.
=============================================================================
Minor refactoring to centralise string to enum conversion in a single place
============================================================
This commit extends SketchGeometryExtension to store within a Geometry if it is an internal aligment geometry
and which type.
====================================================================
If the Part::Geometry * is nullptr, then it is convenient to have a
std::unique<GeometryFacade> that contains a nullptr too, because many
functions check for a Part::Geometry being a nullptr.
======================================================================
GeometryFacade is added the ability to get the construction status via static function, for
convenience in situations where only the construction status is necessary and a geometry facade
would not be otherwise necessary.
A new type GeometryTypedFacade is added, for situations in which the specific Part::Geometry derived
type is known (or is to be created). This Typed version enables to directly access the Geometry derived
class without the need for casting, as well as the SketchGeometryExtension information.
For example, this is possible:
auto HLineF = GeometryTypedFacade<Part::GeomLineSegment>::getTypedFacade(HLine);
HLine->getTypedGeometry()->setPoints(Base::Vector3d(0,0,0),Base::Vector3d(1,0,0));
If a facade is requested without passing an Part::Geometry derived object, the constructor
of the indicated geometry type is called with any parameter passed as argument (emplace style):
auto HLine = GeometryTypedFacade<Part::GeomLineSegment>::getTypedFacade();
HLine->getTypedGeometry()->setPoints(Base::Vector3d(0,0,0),Base::Vector3d(1,0,0));
HLine->setConstruction(true);
ExternalGeo.push_back(HLine->getGeometry());
Using either GeometryFacade or GeometryTypedFacade is probably a matter of style and of the specific situation.
========================================
This is a light-weight c++ only geometry extension to enable migration of information that was stored within
the Part WB and should be migrated to another WB (for example Sketcher WB)
It is designed so that a single extension can migrate different types of data (current and future).
When new data needs to be migrated, first a new enum bit is to be added to the class enum and new data members are to
be added to store the information within GeometryMigrationExtension class.
In the Restore() function restoring the data to be migrated, a GeometryMigrationExtension extension is added to the
geometry to be migrated with the data information and the corresponding enum bit set.
In the object to receive the migration data, onDocumentRestored() it is checked whether an extension of type
GeometryMigrationExtension is present, if yes, it is checked whether a bit used for migration is set and, if yes,
the data is retrieved and the GeometryMigrationExtension extension (preferably) removed from the Geometry object.
===================================
Encapsulate Part::Geometry data member copy process in a single function (copyNonTag).
Part::Geometry derived classes need not know the specifics of the data member of Part::Geometry.
Change the delegation of the copy of extensions from clone() to copyNonTag. Because clone() relies on
copy() and now copy() of Part::Geometry data member relies on copyNonTag(), there is no actual change
to the clone() functionality, but the copy() funcionality gains the copy of the extensions via copyNonTag().
This commit adds SVG files with icons for these commands. Also, it makes the necessary changes on CommandDoc.cpp, CommandWindow.cpp, CommandStd.cpp and resource.qrc files.
