Internal geometry knot points, which were added as fixed parameters to the solver according to a previous commit, are tracked in the corresponding bspline as solver level,
without being a parameter to the solver, and upon solving, the position thereof is updated by means of OCC functionality.
This allows to show the knot points and solidarily move them when moving a bspline.
=================================================================
Very important remark:
Until now, points could not be construction = true.
For now on, if a point is construction = true, the solver will ignore it.
When drawing (snapping) using the Draft module, it is now possible
to press the Q key to record points. Additional snap locations then
become available orthogonally to these hold points.
It seems on some system calling QTreeWidgetItem::takeChildren and then
addChild back is expensive. This fix avoids that but still keeps track
of item order in claimed children
This commit implements the directory-existence-check already used for
the Mod folder when AddonManager attempts to install something into it
and is associated with bug #00029998
When applying dressup, the dressup became the new parent of the path feature object.
Then, in the getToolControllers() function, obj does not point systematically to the parent job.
An existing function findParentJob() is more suitable as it looks for the job also into grandparents.
Some "valid" shapes are being passed to findShapeOutline where edges
that should be connected are in fact separated 10x the expected tolerance
(2*Precision::Confusion) for 2 overlapping TopoDS_Vertex.
IntTools_Tools:ComputeVV also reports these Vertices as further apart than
their combined tolerances should allow.
This change introduces a tolerance into DrawUtil and EdgeWalker vertex
comparisions that is quite "sloppy" (0.00001) but which handles the sample
objects correctly. This tolerance is adequate for drawings. Other uses
should be considered on case by case basis.