* Fixes spelling of "Allow to" to "Allow one to"
and those variants:
Allows to -> Allows one to
allow to -> allow one to
allows to -> allows one to
* Fix "Let's -> Lets"
(and lower case variant.)
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update src/3rdParty/salomesmesh/inc/MED_Wrapper.hxx
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
* Update src/Base/PyObjectBase.cpp
Update src/App/ExtensionContainer.h
Update src/App/PropertyContainer.h
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
* Use gerund in user-facing texts.
* Use gerund for two more user-facing strings.
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
* Update src/Mod/Fem/App/FemMeshShapeNetgenObject.cpp
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
* Update src/Mod/Fem/App/FemMeshShapeNetgenObject.cpp
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
* Update src/Mod/Fem/App/FemMeshShapeNetgenObject.cpp
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
---------
Co-authored-by: Tobias Frost <tobi@debian.org>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
=========================================================
issue #11183
Feature request.
Instead of repeating over and over again the same message, indicate the number of consecutive repetitions in a single message.
============================================================================
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.
===========================================
QT has a open bug regarding filling the contents of a QMenu in aboutShow:
https://bugreports.qt.io/browse/QTBUG-54421
This commit presents a work-around this bug.
The two step procedure of this commit, forces a recalculation of the size
from the slot and then manually moves the widget to the right position.
========================================================================
The NotificationBox is extended to take the QRect in global coordinates. Then
it will try to dimension the label within this area. If a fixed width is provided, that
is enforced (take precedence).
The NotificationArea passes the QRect of the main window to the NotificationBox.
This is intended to fix:
https://github.com/FreeCAD/FreeCAD/issues/8940
======================
A notification area consisting of one area for non-intrusive notifications, and a widget showing previous
errors, warnings, critical messages and notifications.
Notifications being marked with QT_TRANSLATION_NOOP with context "Notifications" are translated.
Messages are shown during a minimum show time, unless pop up (clicked inside). Messages stay until
a maximum show time. Between the minimum and the maximum show times left mouse button events make
the non-intrusive notification disappear.
The widget stores a configurable amount of messages after which old messages are removed to make room for
new ones.
Unread messages are shown in bold.
