==================================================================================
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.
=======================================
Refactor:
- Substitute the use of variadic templates with parameter packs.
- Use recently incorporated external library "fmt" to handle printf like formating.
- Extensive cleaning of pragmas and unnecessary forward declarations.
- Parameter packs and libfmt provide a much stronger type checking now, so
conversions that are by standard implicit as bool to int need an explicit static_cast
to avoid compilation warnings.
Extension:
- Include a notifier field, so that the originator of the message can be provided. E.g. Document#DocumentObject
- Include a new type of message called CriticalMessage, this message is intended to have
special behaviour in the future. Namely, it will be used to notify forward compatilibity issues.
It will be used to substitute the current signal/slot mechanism.
- Include two new types of messages for user notifications (Notification and TranslatedNotification). This messages
will be use to convey UI notifications intended for the user (such as non-intrusive message about the usage of a tool). There
are two versions to mark whether the string provided as a message is already translated or not. When using the console system for
notifications, these notifications may originate from the App or the Gui. In the former, it is generally the case that the strings
of messages are not (yet) translated (but they can be marked with QT_TRANSLATE_NOOP). In the latter, often the messages to be provided
are already translated.
Python support for CriticalMessage, Notification and TranslatedNofification, including shortcuts:
Crt = FreeCAD.Console.PrintCritical
Ntf = FreeCAD.Console.PrintNotification
Tnf = FreeCAD.Console.PrintTranslatedNotification
Related #6097
Qt ignores shortcut of actions in invisible toolbar, but not for actions
in a hidden menu action of menu bar, which is likely a Qt bug. The
desired behavior should be that of toolbar actions, so that actions
belong to different workbenches can have the same shortcut without
conflict.
This commit works around this inconsistency by ensuring only the active
actions are added in menu bar. In addition, all active actions will be
added to a zero sized child widget of the main window, which ensures the
shortcuts of these actions being active regardless whether the action is
in toolbar or menu bar, visible or not.
