=================================================================================
fixes#9208
Essentially:
- The regular mechanism to save toolbar state when changing from one WB to another
is not designed to support changes within one WB (e.g. from edit mode and back).
- At creation time, toolbars can be initialised with default visible or default hidden
state. Additionally, there is third configuration "Unavailable", which refers to a
toolbar that is hidden, and the control to enable it is also hidden by default.
- The ToolBarManager is extended to enable to set the State of one or more toolbars.
- The State refers to changes to be effected on one or more toolbars by client code:
* ForceHidden allows to hide a toolbar and also hide its control (a toolbar not available
in a mode).
* ForceAvailable allows to make a toolbar available by making its control visible, the
toolbar itself is visible or not depending on user settings.
* RestoreDefault allows to bring the control visibility to the default of the toolbar, the
toolbar itself is visible or not depending on user settings.
* SaveState allows to store the current visibility state of a toolbar. It enables client
code to save the state when appropriate. It provides the only option for default "Unavailable"
toolbars, which are fully managed by client code. It provides additional flexibility to save
other toolbar visibility on request.
For the Sketcher this means:
- That edit mode toolbars are not shown outside edit mode.
- That edit mode toolbars and non-edit mode toolbars can be configured independently.
- that edit mode toolbars' state is saved when leaving edit mode if and only if, the
workbench that is selected when leaving edit mode is the Sketcher WB.
- it won't save the state if the user manually selected another WB and then left edit
mode (why? see limitation above).
Limitation:
- When switching to another WB while in edit mode, the other WB is activated before the
current WB (sketcher WB) is deactivated. This means that at sketcher level, the sketcher
has no chance to save states or do other tidy up actions before the tools of the other WB
are activated.
- This, however, is understood as not relevant enough as to warrant changing the mechanisms
in place.
=======================================================
The original coding grouped normal and construction geometries together regardless of the actual order.
If construction geometries where interleaved with normal geometries, all normal would be grouped into a single
list and all construction into another.
This causes a problem that indices referenced in constraints may not match.
This commit fixes this behaviour. While still creating as much geometries together as a list, as many lists as
necessary are created to keep the order of creation.
===============================================
Issue description:
https://forum.freecad.org/viewtopic.php?f=3&t=70325https://github.com/FreeCAD/FreeCAD/issues/7520
The general algorithm to calculate normals miserably fails when
the curve is a line segment and the point through which the normal
to a curve is to be drawn is colinear with the line segment.
The solution is to provide specific code for this corner case.
fixes#7520
===============================================
Revisiting all console calls:
- Using the Notification Framework when the user needs to be notified
- Turning them into DeveloperError/DeveloperWarnings when messages are intended only for developers
==========================================================
This commit turns the remaining blocking pop-ups in which the user can only click "ok"
into non-intrusive notifications, depending on the user preferences in settings.
=======================================================
- Better handling for exceptions originating in Python addConstraint.
- Refactor to reuse code for handling of exceptions
========================
Recently the rendering order functionality was temporarely removed, as it interferred with the development of visual layers.
However, the release comes before visual layers are finished and can provide such functionality.
This commit reintroduces the functionality for the release.
In the Elements context menu (Sketcher task panel) the menu text for Sketcher_ToggleConstruction is "Toggle construction line", this should be "Toggle construction geometry". It is not just lines that can be toggled, and this is also the menu text in the main Sketcher menu.
==========================================
fixes#6174
Problem
=======
The popularity contest heuristic was designed to assume that removing one solver constraint from a redundant group would potentially satisfy it.
This means that for sketcher constraints comprising several solver constraints, the sketcher constraint would never be notified as redundant, but
always partially redundant (where the case may be that it is redundant or that it is partially redundant). This happens because after removing one
solver constraint, it may happen:
(a) that no other solver constraint corresponding to the sketcher constraint remains in the redundant group (so it is indeed partially redundant)
(b) that at least one other solver constraint corresponding to the sketcher constraint remains in the redundant group (so if all solver constraints
remain in the redundant group, the sketcher constraint is actually redundant). This happens because solver constraints of a single sketcher constraint
are orthogonal and consequently, a conflict (or redundancy) emanating from removing one of them cannot actually satisfy the group, as it has no effect
on the other.
Solution
========
When popularity constraint decides on one solver constraint, remove any other solver constraint of the same tag (i.e. same sketcher constraint) that is
present in the conflict group (case b). This does not affect case a, because the solver constraint that is not redundant is not present in the conflict
(redundancy) group.
