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.
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.
===========================================================
This constraint command is basically never used by users and almost never by power users.
If it is not removed is because it may be useful for debugging... and maybe we should think about
removing the command althogether, as debugging can be done via Python console.
==========================================================
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.
================================
New deleteGeometries function, according to the comment should the same
as deleteGeometry but at a time. However, this is not accurate, as deleteGeometry
deletes any internal geometry associated to the provided GeoIds, whereas
deleteGeometries does not delete that internal geometry.
Solution:
Split deleteGeometries into two different functions:
1) delGeometriesExclusiveList
2) delGeometry
The former will not delete associated internal geometry. It is more efficient, but
it is the resposibility of the caller not to leave internal geometry undeleted.
The latter, implemented in terms of the former, will delete associated internal
geometry too.
As a bonus, the latter will also remove any GeoId duplicates.
=========================================================================
Sometimes it happens that malformed constraints are arrived to.
Example:
https://forum.freecadweb.org/viewtopic.php?f=3&t=53780#p463271
It is not the first time. They usually go under the radar and when they are
detected is too late to know what caused them. The user is desperate too.
This commit makes malformed constraints to prevent the recompute of the project.
This is in the best interest of the user.
