==================================================================================================
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.
===============================================
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.
Rendering scalable icons from .svg
The size of the icons is related to the font size of the constraints.
Calculations and access to settings are collected in one place.
Default based on system font size.
And also Symbol for diameter and radius.
==========================================================
When selecting a list of geometry, where at least one element has internal geometry, together with the internal geometry
produced an error in the report view.
Solution:
Use newly exposed deleteGeometries to delete all geometries at once.
Note:
The list is not reverse sorted (as opposed as with the deleteGeometry method), as the list will be sorted
by SketchObject in the normal order. Reverse sorting would lead to the worst case for that normal order sort.
=======================================================
ViewProviderSketch relies on new property SketchObject::FullyConstraint to show status via overlay icon
==================================================
ViewProviderSketch now derives from the ViewProviderAttachExtension and gets the overlay icon when not attached.
ViewProvider2DObject does not implement a ViewProviderAttachExtension although Part2DObject (on which SketchObject derives)
does derive from AttachExtension. It is understood that this is because this functionality is unwanted for other
ViewProviders.
=====================================================================
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.
