2 weeks ago the properties EndTypeScale and LineVisible were added but not to the dialog.
This PR adds them t the balloon dialog-
It also took the opportunity to cleanup the code:
- add missing tooltips
- uniform tooltips in App and Gui
- uniform the UI element names
Many Path object forward its editing operation to the job object. It is
possible that some editing option change may lead to removing of the
editing object (e.g. changing stock type) causing crash. It is possible
to just open the task panel without setting any editing object by
returning False in ViewProvider.setEdit()
as reported here: https://forum.freecadweb.org/viewtopic.php?f=35&t=53664 the balloon text separation no longer works.
The regression was introduced by commit 05577c267 . The mistake thereby was that the textHeight is already handled before the separators and that rectangular balloons behave differently because of the separator feature.
as discussed here: https://forum.freecadweb.org/viewtopic.php?f=35&t=53680&p=461356#p461349
* change default tolerance scale to 0.8
* the tolerance scale is directly applied, thus it must have non-italic label
* move tolerance scale to "Dimensions" tab
* move Fuzz settings to "Advanced" tab
* move Conventions to General tab since e.g. the projection angle is an important general setting
* add a note for the label font that this is also used for dimensions and that it there only has an effect for new ones
* use more useful step size of 0.1 for some scaling spinboxes
* sort UI fields in the C++ code to avoid doubled or missing entries (there were 2 doubled entries)
* uniform width of all preferences dialogs
* better alignment for the HLR dialog
========================================
Previous versions relied on a heuristic that proved insufficient for cummulative use of the Block constraint.
The effect is that Block constraints stopped blocking, which is a major bug, as it lead to inadvertedly moving
geometry that was supposed to be blocked.
Fixes:
https://forum.freecadweb.org/viewtopic.php?f=13&t=53515&start=30#p461215
(Thanks Chaospilot)
Know problems with old block constraint (v0.18):
1. If driving constraints were present, they were ignored if inserted before the block constraint (to avoid
redundancy/conflicting). They resulted in
Principles of Working of the new block constraint:
1. Handling of the new block constraint is based two processes, a pre-analysis and a post-analysis. Pre-analysis
works *before* diagnosing the system in the solver. Post-analysis works *after* diagnosing the system in the solver.
2. Pre-analysis is directed to detect geometries affected *exclusively* by a block constraint. This is important
because these geometries can be pre-fixed when creating the solver geometry and constraints before GCS::diagnose()
via initSolution() AND because if no other constraint affects the geometry, the geometry parameters won't even appear
in the Jacobian of GCS, so they won't be reported as dependent parameters (for which post-analysis would be of no use).
3. Post-analysis is directed to detect Geometries affected *not only* by a block constraint. This is important
because pre-fixing these geometries would lead to redundant constraints. The post-analysis, enables to fix just the
parameters that fulfil the dependacy groups.
4. Post-analysis basically identifies which parameters shall be fixed to make geometries having blocking constraints
fixed, while not leading to redundant/conflicting constraints. These parameters must belong to blocked geometry. This
is, groups may comprise parameters belonging to blocked geometry and parameters belonging to unconstrained geometry. It
is licit that the latter remain as dependent parameters. The former are referred to as "blockable parameters". Extending
this concept, there may be unsatisfiable groups (because they do not comprise any bloackable parameter), and it is the
desired outcome NOT to satisfy such groups. It must be emphasised that there is not a single combination of fixed parameters
from the blockable parameters that satisfy all the dependency groups. However:
1) some combinations do not satisfy all the dependency groups that must be satisfied (e.g. fixing one group containing
two blockable parameters with a given one may result in another group, fixable only by the former, not to be satisfied).
This leads, in a subsequent diagnosis, to satisfiable unsatisfied groups.
2) some combinations lead to partially redundant constraints, that the solver will silently drop in a subsequent diagnosis,
thereby reducing the rank of the system fixing less than it should.
5. The implementation rationale is as follows:
1) The implementation is on the order of the groups provided by the QR decomposition used to reveal the parameters
(see System::identifyDependentParameters in GCS). Zeros are made over the pilot of the full R matrix of the QR decomposition,
which is a top triangular matrix.This, together with the permutation matrix, allow to know groups of dependent parameters
(cols between rank and full size). Each group refers to a new parameter not affected by the rank in combination with other free
parameters intervening in the rank (because of the triangular shape of the R matrix). This results in that each the first column
between the rank and the full size, may only depend on a number of parameters, while the last full size colum may dependent on
any amount of previously introduced parameters.
2) Thus the rationale is to start from the last group (having **potentially** the larger amount of parameters) and selecting as blocking
for that group the latest blockable parameter. Because previous groups do not have access to the last parameter, this can never
interfere with previous groups. However, because the last parameter may not be a blockable one, there is a risk of selecting a parameter
common with other group, albeit the probability is reduced and probably (I have not demonstrated it though and I am not sure), it
systematically leads to the right solution in one iteration.
GCS: Change dependency group from std::set to std::vector to prevent reordering of parameters.
When using linear pattern with expression, this can be usefull to have only one
occurence (the original one), which can't be done with the following
implemenation. This commit change this behaviour by allowing this value.
==============================================================
Previously construction points was used to code bspline knots.
Now construction points are normal sketcher points, which can be
made defining.
This commit renames and adapts the checks for fixed geometry.
fixes:
https://forum.freecadweb.org/posting.php?mode=quote&f=3&p=461472#pr461472
=====================================================================
Finish checks with geometry pointer before calling initTemporaryMove(), as the pointer may change as a result of the solve() operation.
========================================
Report:
https://github.com/FreeCAD/FreeCAD/pull/4183https://github.com/realthunder/FreeCAD_assembly3/issues/387
Problem:
renameConstraint() previously implemented exclusively in SketchObjectPyImp.cpp,
will change the Constraints property without updating the solver. A prospective
drag operation would rely on a deleted pointer constraint which leads to the
crash.
Solution:
- mark the solver status as needing an update
- leverage new through sketchobject r/w interface to ensure solver is synchronised
before the temporary move operation starts
Bonus:
move the core of the function to SketchObject.cpp so that input data validity
check on constraint change is inhibited.
=========================================================
-> 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).
=============================================================================
The reduced Jacobian defaults to the size of the full Jacobian, where driven constraints
and parameters are not considered to build the reduced Jacobian and thus empty rows remain.
This is generally not a problem as QR decomposition ignores this rows, except in case where
only driven constraints exist. In such a case no QR decomposition is necessary, and in fact
relying on the size of the QR decomposition leads to the incorrect result that the sketch
is fully constraint, when the opposite is true.
This commit resizes an effectively empty reduced Jacobian to avoid this issue.
Fixes the problem that a line with a single reference constraint is shown as fully constraint.
- add missing class to UI file (found and automatically added by Qt Designer)
- add more sensible stepsize - you are dealing in practice with rations in the range 1.2 - 1.6 thus a stepsize of 1.0 is not helpful
as discussed here: the wording "datum color" does not make clear what it is about. It is in fact the color for dimensional constraints, thus name it as such
- also fix the dialog height (found and automatically corrected by Qt Designer)
QAction defaults menu role to TextHeuristicRole, which causes qt to
guess the menu role based on action title. And titles start with
'Config', 'Options', 'Settings', etc. will be considered as preference
menu. It seems some non-english translation causes the wrong action be
chosen as preference, such as 'Treeview actions'.
This commit just applied a temporary fix to default to QAction::NoRole
for GroupCommand. If there is ever some GroupCommand need to be a
system menu item on macos, we could add some command bit flag for that
purpose.
