=====================================================================
Finish checks with geometry pointer before calling initTemporaryMove(), as the pointer may change as a result of the solve() operation.
=========================================================
-> Split read and read/write operations
New interface to access the solver object (Sketch) of SketchObject is now read only (const):
const Sketcher::Sketch &getSolvedSketch(void) const;
-> Encapsulate solver r/w access in SketchObject
Rationale:
- r/w access (access to non-const functions of the solver) leads to unsynchronised solver status.
- Before this commit there was a non-enforceable shared responsibility between ViewProviderSketch
and SketchObject.
- This commit centralises r/w access in SketchObject and SketchObject takes responsibility for doing whatever
necessary so that the solver is synchronised as appropriate.
- For read-only access (const functions) it is possible to use at ViewProviderSketch getSolvedSketch() returning
a const reference to the solver object.
- As it regards the advanced solver configuration dialog, it has been modified to configure by const-casting that reference. This
is not optimal, but it is deemed acceptable, because it should be rewritten sooner or later to include only useful information
and the configuration probably centralised in an individual configuration object, possibly compatible with several solvers
(e.g. DeepSOIC's ConstraintSolver too).
=====================================================================
Provide different colors for full constrained edge, construction edge, internal alignment element and construction vertex.
This should enable users to select what they want in their specific situation.
==========================================================
The order of any operation, including setedit is first solve() and then draw().
This is consistent with geometry addition.
If ViewProviderSketch must insert its own extensions, for example for scaling
weights, then it is its responsibility to set this information wherever needed.
This includes the temporal geometry vector used in draw(true), the solver to
enable dragging operations, and SketchObject Geometry property.
===============================
Fixes:
https://forum.freecadweb.org/viewtopic.php?p=458293#p458293
Rationale:
In order to fix B-Spline pole dragging, the order was inverted.
This fixed the B-Spline pole dragging issue, but introduced a
draw before solve approach that is not consistent with the rest
of the Sketcher.
In my parallel development I had already identified this inconsistency,
switched the order, and provided a new mechanism to fix the issue with
the B-Spline pole dragging. This will be merged as part of another PR.
In the meantime, this PR restores the intended behaviour, and let us
identify if the particular reported exception also happens in other
situations.
=============================================================================================
This commits removes the Geometry construction data member and adapts sketcher code to use
GeometryFacade to access construction information via the SketchGeometryExtension.
==========================================================
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.
- fix sign/unsign comparison warning
- show intent in for loop comparison, values inside the loop over size() are not intended and are undesirable
- do not use itw for an index, as it evokes an interator - it -
- BSpline Weight on information layer positioned one line under Knot multiplicity
When working with weights, it is a huge improvement to see the weights immediately when changing the pole circle radius.
This PR adds an option to display the weights.
When the sketch is not in XY plane, individual constraints from the merged constraint icon can't be selected. Constraint icon coordinates are given in sketcher coordinates. The function getCoordsOnSketchPlane projects vector in global coordinates to the sketch plane. So, it makes no sense to use sketcher coordinates with it. If the sketch is in the XY plane, then the global coordinates are the same as sketcher coordinates. The solution is to get global coordinates of the icon from the sketcher coordinates and use it to project icon to the screen.
* Change the formula to calculate maximum distance for merging of constraint icons.
* Ignore z coordinate while calculating the distance between icons. It is irrelevant but can slightly differ between icons.
* Choose first icon from the group of nearby icons as a location of the composite icon, instead of choosing icon closest to the average position. Fixes jittering of the icon while one of the constraints is moved.
Constraint icons that located close to each other get merged into a single icon. If you zoom in, individual constraints on these icons can't be selected anymore because their relative positions, which must depend on the zoom, don't change. The problem is solved by multiplying relative position by the scale factor which depends on the magnification.
==============================================================================
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 App:Document::undo, applchn is called on every transactional object (e.g. properties) affected, which
calls Paste on the property.
Each of the properties of SketchObject cause a call to SketchObject::OnChanged, and App::DocumentObject::OnChanged, the latter
calling onChangeProperty, which signals the viewprovider from Gui::Document::slotChangedObject via ViewProviderSketch::updateData.
This causes that the ViewProvider is updated when Constraints and Geometry indexes are not matching.
The solution proposed has three parts:
1. First, at ViewProvider::updateData update is prevented while undo/redo transaction is performed by checking isPerformingTransaction()
2. Second, the onUndoRedoFinished() mechanism of SketchObject causes the call of updateData when it solves the sketch (and sets the solved geometry)
3. Third, Gui::Document::signalUndoDocument and Gui::Document::signalRedoDocument (via the slots in ViewProviderSketch) are
used to perform the recompute of the ViewProvider when the undo/redo transaction is finished if needed.
===================================
Encapsulation of grid internals in ViewProviderObject2D, while allowing control via property changes and protected functions.
... all options are freely accessible in the preferences editor ...
... eg. no need to check 'Show Grid' to customize grid size or snap
Also remove the sparse automatical saving to preferences from sketcher Task pane ...
... (some settings were saved, some not)
======================================================================
fixes#3831
Solver Interface getPointId method is only intended for normal geometry, and returns -1 if geoid is out of range, which was misinterpreted as root point selection.
+ remove unneeded class members from EditData class
+ do not include ui-header from within header files
+ fix possible memory leak in EditDatumDialog
+ when canceling dialog make sure sketch will be updated
This integrates the ability to manage dimensional constraint driving/driven status
in the constraint edition dialog box.
It adds a checkbox in the dialog to show/select whether a constraint is driving or
driven. When the constraint value is modified, it is automatically set as driving.
Main focus is to allow to edit name (alias) of reference (driven) constraints
directly in the constraint edition box.
Resolves#3793, #3978
Derived from App::DocumentObjectT to add support of sub object
Also some minor changes to App::DocumentObjectT
Changed Gui::SelectionChanges to make use of SubObjectT
