================================================
Problem:
Command execution templates currently are send to Console() error,
which sends messages to both developers and users.
A user sees an error message (for example in the notifications area)
which is just the Python command that FreeCAD executed due to user's
input. This annoys users who do not understand Python and it is not
informative for them.
It is however informative for a developer, who can associate which
command produced which error/exception.
Solution:
To make these messages intended for the Developer only. So that regular
users are not annoyed.
Of course, Developers and power users can always select in preferences,
under Notification Area to be shown debug errors and warnings. In which
case nothing really changes.
================================================================
https://github.com/FreeCAD/FreeCAD/issues/9208#issuecomment-1567469254
Issue:
- Unavailable toolbars default to not visible (as they are unavailable)
- However, when made available, they remain not visible. There may be
cases when this is indeed the wanted behaviour, but they are not the
ones we are facing.
- In the latter, the user expects the toolbars to show (and the
configuration file to be saved with all toolbars showing.
Solution:
- Change the default behaviour of Unavailable toolbars when forcing
them to be available, so that they are visible when made available.
- If then the case arises that we have toolbars where we would prefer
then to be left not visible when making them available (so they are
listed in the toolbar context menu to make them visible, but not
visible per default), then we would need to create another toolbar
policy class "UnavailableHidden".
- I chose not to add it directly (although it is straightforward) in
fear that we will never need it, and it would make the code more
complex to understand and thus maintain.
=================================================================================
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.
Following the example of Arch_Wall:
- Fixed object name.
- Default label is translatable.
- Name argument should only be used for the label and not be translated.
=======================================================
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
