Eliminate the Python interpreter warning about failure to close a stale handle when using the `exec(open('%s').read()` idiom, enclosing it in a `with` clause.
Add the optional Qt::MSWindowsFixedSizeDialogHint parameter to all uses of the QInputDialog::getX static functions to silence a Qt/Windows debug mode warning about QWindowsWindow::setGeometry: Unable to set geometry. Increase the size of the unit calculator to eliminate the same warning. Finally, call adjustSize() on the "Unsaved Changes" dialog to silence the warning.
=================================================================================
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.
