===============================================
On Undo/Redo there should not be an unconditional recompute.
The need for this recompute is probably related to the fact that PropertyConstraintList
has invalid geometry keys.
=======================================================================
On App:Document::undo, applchn is called on every transactional object (e.g. properties) affected, which
calls Paste on the property.
Each of the properties of SketchObject cause a call to SketchObject::OnChanged, and App::DocumentObject::OnChanged, the latter
calling onChangeProperty, which signals the viewprovider from Gui::Document::slotChangedObject via ViewProviderSketch::updateData.
This causes that the ViewProvider is updated when Constraints and Geometry indexes are not matching.
The solution proposed has three parts:
1. First, at ViewProvider::updateData update is prevented while undo/redo transaction is performed by checking isPerformingTransaction()
2. Second, the onUndoRedoFinished() mechanism of SketchObject causes the call of updateData when it solves the sketch (and sets the solved geometry)
3. Third, Gui::Document::signalUndoDocument and Gui::Document::signalRedoDocument (via the slots in ViewProviderSketch) are
used to perform the recompute of the ViewProvider when the undo/redo transaction is finished if needed.
=============================================
New mechanism for on-demand signaling of undo/redo transaction finalisation.
The mechanism consists of:
1) A status bit that is set, when an object should receive this signaling (e.g. because changes during transaction have been inhibited)
2) The new function to be called by the Document undo/redo actions when the transaction is over (for those objects having the status bit set).
Note 1: The undo/redo signals are now outside the undoing FlagToggler, this means that:
1) a call to isPerformingTransaction will return false.
2) a recompute the slot of such a signal will not be inhibited.
Note 2: The undo/redo signals are called once the documentobjects that requested to be notified after the trasaction is over have been notified.
The consequence is that the viewprovider can rely on the documentobject having a correct status.
I think that the behaviour of Note and Note 2 is the wanted behaviour of this signals, I cannot rule out that other parts of FC rely on the old
implementation.
this is unnecessary since Qt will automatically use the available font. It only raises questions since one see in the commit diffs that depending on who modified the dialog, his system default font will appear. (like in the initial commit of this PR)
- I had a look at Crowdin and saw that the translators don't know what to do with the uppercase letter words. And in fact we can use "normal" terms
- I also fixed a typo (missing 'd') to be consistent
'QString& QString::vsprintf(const char*, __va_list_tag*)' is deprecated: Use vasprintf(), arg() or QTextStream instead [-Wdeprecated-declarations]
'QString& QString::sprintf(const char*, ...)' is deprecated: Use asprintf(), arg() or QTextStream instead [-Wdeprecated-declarations]
Since Py3.3: 'Py_ssize_t PyUnicode_GetSize(PyObject*)' is deprecated [-Wdeprecated-declarations]
Since Py3.9: 'PyObject* PyEval_CallObjectWithKeywords(PyObject*, PyObject*, PyObject*)' is deprecated [-Wdeprecated-declarations]
Since Py3.9: 'void PyEval_InitThreads()' is deprecated [-Wdeprecated-declarations]
- everything that is part of the drawing should be plain SVG (strictly following the SVG specification) to assure that every SVG program can handle it (e.g. Internet browsers).
The hatch patterns however contained old stuff like traces of Sodipodi that might be a problem in the future.
