Fixes Coverity issue:
CID 316539 (#1 of 1): Uninitialized scalar field (UNINIT_CTOR)
uninit_member: Non-static class member lastHasPartialRedundancies is not initialized in this constructor nor in any functions that it calls.
=================================================
Knot position is not calculated by the solver, but by OCCT when updating the
b-spline to conform to given pole positions, as mandated by the solver. Before
this commit, all constraints driving and non-driving operating on the knots required
and extra solve (from advanced solver dialog, or from the Python console), or a recompute
to be recomputed.
This commit introduces transparently re-solving at Sketch.cpp level if B-Splines are present,
so that when the Sketcher mandated solve returns, the geometry is fully solved.
========================================
The geometry state stored in the geometryFacade is modified following a mutable model
(without setting the Geometry property on Constraint change), in order to avoid coupling
the addition/removal of a constraint with a change of the Geometry Property.
This design decision however interferes with the ability of the Geometry property to restore
the correct geometry state upon redo/undo.
While such a situation is rare in the case of Internal Alignment geometry, because constraint
addition/removal is performed with the corresponding geometry addition/removal (within the same
transaction. That is not the case with the Block constraint (or another future general case where
the geometry state may be applied).
This commit leverages the synchronisation mechanism already in use for non-properties (e.g. external geometry or
vertex indices) to check and synchronise geometry state upon undo/redo and restore.
Bonus:
- addGeometryState is refactored to separate the checking logic from the setting logic.
Currently the sketch fillet tool deletes any constraints associated with
the two lines to be filleted. By leaving a vertex at the intersection,
we can instead preserve most constraints in reasonable ways.
Sketch fillet horizontal and vertical point-to-point constraint support
Also better future compatibility for point constraints, and some minor tweaks.
============================================================================
This specific constraint removes the free parameter of the previous implementation. This solves:
https://tracker.freecadweb.org/view.php?id=4501fixes#4501
However, this implementation of equal size produces zero gradients when coordinates of lines are aligned,
e.g. vertical or horizontal. These zero gradients, which are mathematically right ruin the diagnosis, which
regards corresponding elements as fully constraint (because they are locked from a solver point of view), when
they are simply locked, but are movable and constrainable. For this, when the rightful gradient is small enough
(<1e-10) it is substituted by a surrogate gradient of 1e-10, which solves the problem with the diagnose, which
treats as zero only values under 1e-13 (pivot threshold used in QR decomposition).
This special behaviour fixes the wrong detection here:
https://forum.freecadweb.org/viewtopic.php?f=8&t=53466&start=40#p464168
It also fixes this one:
https://forum.freecadweb.org/viewtopic.php?p=468585#p468587
==================================================================================================
Coin documentation indicates the size of a font is:
SoSFFloat SoFont::size Size of font. Defaults to 10.0.
For 2D rendered bitmap fonts (like for SoText2), this value is the height of a character in screen pixels. For 3D text, this value is the world-space coordinates height of a character in the current units setting (see documentation for SoUnits node).
However, with hdpi monitors, the coin font labels do not respect the size passed in pixels:
https://forum.freecadweb.org/viewtopic.php?f=3&t=54347&p=467610#p467610https://forum.freecadweb.org/viewtopic.php?f=10&t=49972&start=40#p467471
Because I (abdullah) have 96 dpi logical, 82 dpi physical, and I see a 35px font setting for a "1" in a datum label as 34px,
and I see kilsore and Elyas screenshots showing 41px and 61px in higher resolution monitors for the same configuration, I think
that coin pixel size has to be corrected by the logical dpi of the monitor. The rationale is that: a) it obviously needs dpi
correction, b) with physical dpi, the ratio of representation between kilsore and me is too far away.
This means that the following correction does not have a documented basis, but appears necessary so that the Sketcher is usable in
HDPI monitors.
========================================================
With the possibility to increase icon sizes via font configuration, the
default hardcoded 2.5 step for seeking the constraint position becomes too
small, causing constraints, specially when multi-icon, to superimpose geometry points,
removing the ability to pick them.
Changing the default gives some increased room for icon size.
==============================================================
A previous commit assumed values for lineWidths and pointSizes were integers. This commit fixes this.
=========================================================================================
- Long overdue refactor to avoid repetition during save/restore and copy.
- New interface to notify an extension when it is attached. It also enables the extension to gain
a pointer to the geometry container. This is intended to extend the functionality already existing
in Part::Geometry.
==================================================
In addition to the font size in pixels, which controls the 3D View font size (and indirectly the constraint icons),
it is now possible to configure a scaling factor controlling the width of geometry, axes, information layer, and
constraint lines.
===============================================
Based on PRs #4146#4155.
PR #4155 proposes a scaling factor to be used to scale up constraint icons and the subindex font of icons. The
scaling factor is a parameter.
PR #4146 proposes to derive the constraint icon size from the system font size via function of the dpi. The
constraint icon subindex is a factor of the constraint size.
Observations:
- PR #4146 identifies the need for a scaling factor too, but this is a hardcoded 1.25 factor.
- PR #4146 appears to mix font points and font pixels when deriving the sizes.
- PR #4155 deals exclusively with icon size and subindex font, not with constraint label
Useful concepts:
- Font point is a physical distance. There are 72 points in one inch.
- Monitors have pixels with varying pixel densities. The number of pixels in one point varies
with pixel density. Hence the need for a correction based on the dpi of the monitor.
API constraints:
- While QT's configuration can be obtained in points or pixels, coin3D sets the font size in points.
Solution:
- Continue relying on the local font setting from preferences for coin3d font, albeit by converting from pixels to points.
- Introduce a sketcher wide 3D view scaling factor, as per #4155. This factor is however used for geometry, not for fonts.
- Geometry is scaled to compensate for the scaling factor and the monitor pixel density (the scaling factor is the product
of both scaling factors).
- Derive the 3D view icon size to be 80% (hardcoded) of the 3D view font size. Having constraint icons proportional to contraint label
font size gives consistency to the interface, as constraint icons also have subindices. I do not think it is worth to provide this 80%
as a configurable parameter
- The constraint icon subindex, being a special case of font relative to the accompanying icon, is set to be the 80% of the
icon size (hardcoded). I think it is not worth to provide this as a configurable parameter.
Bonus:
- ViewProviderSketch implements an observer of parameter group and tracks view scaling factor parameter and marker size.
- On change of parameter the inventor nodes are updated and the 3D view redrawn.
- Size information is moved to edit structure for consistency with Marker size.
