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
==========================================================
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
==================================================================================
Limitations of the current framework:
- Codes the translated state only for TranslatedNotification as part of the type.
- Does not code the intended recipient (user, developer, ...)
Problems:
- Some errors are intended for developers, some errors may only be intended for users,
if, for example, there is another developer error which already contains all the information.
The current framework may lead to information duplication or to showing to the user developer
information, which is perceived as annoying.
- Logs shall be in English (report view), while every message to the user (UI) shall be translated.
The current framework can only differentiate where to report based on subscription (legacy logs do not
subscribe to notifications), and for notifications, whether it is translated or not depends on the type.
It is not possible to code errors or warnings that are already translated.
Solution:
- To extend the ILogger interface with additional metainformation, indicating the intended recipient
(User, Developer, All), and the content of the message (translated, untranslated, untranslatable). The latter
is useful for dynamic strings that won't find a match in the translation framework.
Bonus:
- This extended version allows to do away with translatednotification, as now any message can be independently
marked as translated or untranslated or untraslatable.
- It is now possible to provide the right icon of severity (error, warning, info), even when it is only user intended
and already translated.
