===========================================================================
The former system of autoclosing messageboxes is removed in favour of the Notification Area.
==============================
This commit provides specific behaviour on how to handle user messages signalled by App::Document for the different types of notifications.
For critical messages DURING a user initiated restore (i.e. only if the user clicked in the UI, not applicable for macros or Python initiated):
- The first critical message during restore requires user confirmation by clicking a button in a modal dialog box. The user has the choice to
request to be asked for confirmation for any subsequent critical message during restore or to forgo confirmation.
- If he chooses to forgo confirmation, subsequent critical messages are shown as auto-closing non-modal dialogs in a non-intrusive way. The user
can continue working while this information is shown. There is a maximum of auto-closing non-modal dialgos that can be enqueued. Over this maximum,
A warning pop up indicates this situation, referring to the Report View. No further auto-closing messages are enqueued until all existing messages
have disappeared. This is done to prevent overwhelming the user with notifications in cases where malfunction causes too many notifications to be
generated.
For any type of message OUTSIDE a user initiated restore:
- Messages are shown as non-intrusive non-modal auto-closing messages (it is not possible to generate modal/blocking messages outside a user
initiated restore).
- Messages are enqueued respecting a limit as above.
* On lines where the variable type is obvious from inspection, avoid repeating the type using auto.
* When possible use a ranged for loop instead of begin() and end() iterators
* Use multi-arg instead [-Wclazy-qstring-arg]
* Use an empty QLatin1String instead of an empty QStringLiteral [-Wclazy-empty-qstringliteral]
* getter Gui::ProgressBar::canAbort possibly mismarked as a slot [-Wclazy-const-signal-or-slot]
* Missing emit keyword on signal call [-Wclazy-incorrect-emit]
Replace the int of the 'resolve' argument of several functions with a proper enum class.
* This avoids the inconsistencies in client code where often true/false is passed when an int is expected
* This avoids the use of magic numbers like 0, 1, 2 or the undocumented 3
* Part: fix Placement/Shape onChanged() handling
* App: fix property ordering problem when undo/redo
See https://tracker.freecadweb.org/view.php?id=4265#c14271
* Gui: fix undo/redo signaling
Make sure to signal after all properties has been restored