========================================================
If the restore of Document.xml results in invalid Document.xml (because unhandled exceptions occurred), the
document status Document::restoreError is set. The GUI or Mod/Web if a link was clicked, show a pop-up indicating
this situation.
This commit also shows an appropriate pop-up for the partialRestore when opening from the menu, that before only
appeared when opening by clicking a link.
============================================================================
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
A relative profile can now be used if it references itself. This fixes a compatibility issue with the V0.18 version of ArchRoof, where the first profile initially always references itself.
- Previously a subtractive pipe on a body with no solids would create a solid. Now Pipe will generate an error.
- Fix incorrect property header. Previously Pipe was identifying itself as Pad (copy paste error)
==================================================================================================
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.
also fix issue that tolerance could be set despite theoretically exact is true under some circumstances
also some wording improvements
also a minor fix to use 0.0 instead of DBL_MIN
