=======================================
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
...Renamed to "ILogger", to designate that this is an Interface for a
Logger. This "Interface" is pure virtual, so that it cannot be
instantiated directly. This makes it clear that it is intended to be
derived.
Finally, got rid of all the individual log-style methods and replaced
with SendLog. The idea here is that day-to-day users will only interact
with ILogger through ConsoleSingleton (or, likely, LoggerSingleton in
the future). This singleton will manage an arbirtary collection of
ILogger, and call SendLog with the appropriate parameters based on what
the user requests.
Therefore, the singleton itself will have the individual Log, Message,
Error, etc... methods, while stil allowing us to simplify the code base
of ILogger and its derived classes.
