=============================================================================================
This commits removes the Geometry construction data member and adapts sketcher code to use
GeometryFacade to access construction information via the SketchGeometryExtension.
========================================
This is a light-weight c++ only geometry extension to enable migration of information that was stored within
the Part WB and should be migrated to another WB (for example Sketcher WB)
It is designed so that a single extension can migrate different types of data (current and future).
When new data needs to be migrated, first a new enum bit is to be added to the class enum and new data members are to
be added to store the information within GeometryMigrationExtension class.
In the Restore() function restoring the data to be migrated, a GeometryMigrationExtension extension is added to the
geometry to be migrated with the data information and the corresponding enum bit set.
In the object to receive the migration data, onDocumentRestored() it is checked whether an extension of type
GeometryMigrationExtension is present, if yes, it is checked whether a bit used for migration is set and, if yes,
the data is retrieved and the GeometryMigrationExtension extension (preferably) removed from the Geometry object.
===================================
Encapsulate Part::Geometry data member copy process in a single function (copyNonTag).
Part::Geometry derived classes need not know the specifics of the data member of Part::Geometry.
Change the delegation of the copy of extensions from clone() to copyNonTag. Because clone() relies on
copy() and now copy() of Part::Geometry data member relies on copyNonTag(), there is no actual change
to the clone() functionality, but the copy() funcionality gains the copy of the extensions via copyNonTag().
When using gcc 10 and PyCXX 7.1.4 on Fedora there is an error because the conversion from size_t to Py_ssize_t is ambiguous
See https://forum.freecadweb.org/viewtopic.php?f=4&t=52502
The class Py::Tuple is also incorrectly used here and causes a memory leak
- there is no reason to hide it and even a bit tiring to open it manually since most no new primitives should be at the origin
- give the combobox to select the primitive type a reasonable name, this helps to understand the code better
- do not use a QSignalMapper if the slot doesn't take care of the emitting widget
- to set the placement only check for the base class GeoFeature, i.e. no need to step through all primitive types
- fix compiler warning of unused variable
+ add class ViewProviderPrimitive to avoid to re-implement setEdit/unsetEdit methods for each sub-class separately
+ avoid using global variables
+ when editing a feature directly pass it to the dialogs
+ when editing a feature then do not use active document as this could point to the wrong object
+ fix undo/redo message
+ re-add '3D View' button to location dialog
fixes https://tracker.freecadweb.org/view.php?id=3857
Currently primitives of the Part WB can only be created suing a dialog. Editing is not possible that way.
This PR makes the first step in achieving this:
- Helices can now be edited using the same dialog ans when created
- New location dialog. The Gui::LocationWidget used there is not aware of the rotation angle and it treats the rotation axis as direction. To fix this, I set changed the dialog so that one can define every parameter as in the PartDesign attacher dialog (Placement, rotation axis and rotation angle separately). Another reason for this change was that one could not use the location dialog, fill it with the placement properties of the object, and close the dialog without any change. Because of the missing angle info the objects was then always rotated despite nothing was changed.
If this PR goes in, I will extend it for the other primitives.
Todo for the future: allow a preview of the changes made in the dialog. (I could not find out how this is done.)
