===========================================================================
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
This reverts commit b0452667c72f330323f6b3366f45bf039d05feef, reversing
changes made to b2d99f3fa7b4c7c305aed4a8d975a8624a6d590f.
See forums discussion: https://forum.freecadweb.org/viewtopic.php?p=549120
The problem happens when partial loading is enabled. If document A
contains a link to some object in document B, it will load B as partial
document with only that object and its necessary dependencies. But if
document A contains another link to some object in document C which also
has a link to some object in document B, the link in document C may not
be restored, because document B is partially loaded without the linked
object. This patch will check for this case and reload document B for
more objects.
See an example reported in
https://forum.freecadweb.org/viewtopic.php?p=495078#p495078
* Fix lost filename in err msg
In some circumstances, FileExceptions are constructed empty, then have a
filename assigned to them, but the error message in these scenarios is
left as the default "unknown" one, which is sometimes shown to users.
This change fixes that case to be consistent with instances that are
constructed with the filename.
The exception can happen when trying to save the file in a location that does
not exist, or when the user does not have permission to write there. If it
comes when saving after closing the document, all previous changes can be lost.
Partially fixes issue #4098.
Co-authored-by: Heewa Barfchin <heewa.b@gmail.com>
By making sure to signal from the owner document of the editing object.
The owner document of the editing object may be different from the
editing document in case of editing external linked object.
