================================================
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.
=========================================================
Extends notifier types to Gui::Document, App::Document, Gui::ViewProviderDocumentObject.
This allows to pass these objects as notifiers, and the framework gets the right string
from the Label or FullLabel as appropriate.
============================================================================
The old preferences had errors and warnings ON by default and allowed to opt-out.
It was not possible to separate errors/warnings intended for users from those intended for developers.
The new version has developer errors and warnings OFF by default. User intended ones are ON.
It is possible to opt-in for developer errors and warnings from the preferences dialog.
As developer errors and warnings are NOT translated, if opting-in, they won't be localised.
User errors and warnings should be translated. If they are not, it is a bug.
===============================================
With the new console extension, the translation state is coded separatedly.
Therefore, it is possible to code a Notification as translated without needing a specific type.
Additionally, any other message, such as Error of Warning can be translated.
It does not make sense to leave this message, if only for reasons of coherence and to simplify
maintainance of code.
==================================================================================
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.
