Going through this list, I have 2 comments:
- There is a change in plain group visibility toggling behavior. Previously, when a group is hidden, all its (nested) children are hidden by changing the 'Visibility' property of all of them. This is still the same, but the plain group will remember its children visibility before toggling, and will restore the children visibility when the group is shown again.
This corrects a very annoying bug, that is
described here. Assembly4 has a workaround, but if this is not merged all other users of App::Link will be hit by this.
- Another change is that App::Part (OriginGroupExtension) no longer creates origin features by default. This saves six objects per container, which is rather significant for STEP import with large amount of small assemblies, where the majority of the imported container will never need to use the origin feature. To initialize the origin features, simply toggle the visibility of the Origin group
I never liked this "
Origin" thing, so I won't complain if it goes away. Actually, I don't understand why it's even there: why not use Datum Planes, like all other CAD systems in the world do ? The Origin things are similar to Datum Planes and Axes, but inferior in every aspect (you cannot create new ones, so if you want new planes to draw sketches you need to create Datum Planes anyway).
Speaking of Datum objects, today they are from the PartDesign workbench, and belong to the PartDesign:: namespace (please forgive me if it's not the correct technical term). When they are used in a Part container however that leads to warnings in the Report View:
Code: Select all
PartDesign::CoordinateSystem / LCS_1: Links go out of the allowed scope
PartDesign::Plane / DatumPlane: Links go out of the allowed scope
They work perfectly well, do exactly what one would want them to do, they're reliable and I have yet to see 1 occasion when this fails, but still FreeCAD complains with this scary warning message.
So, at minimum, could this useless warning message please be removed ?
Even better, and that's why I write it here, these datum object are in PartDesign for historical reasons, but they would be much better served if they were in the Part namespace, usable directly in App::Part objects. And, hence, also in PartDesign, of course.
Thus, App::Part, App::Link and Part::DatumObjects would form the fundamental building blocks and plumbing interfaces for all FreeCAD assemblies. New solvers could be implemented to solve particular usecases, and if all FreeCAD assemblies use the same assembly data structure they could be compatible. I could very well imagine that architectural, civil engineering, free-form, mechanical engineering, optical engineering, FEM ... problems would need specialized solvers. Assembly4 with the ExpressionEngine would only be one of them. All a solver actually does is to calculate the App::Placement property of an object. It would be a huge gain for FreeCAD users if they all could share the same assembly data structure independently from the solver.
Since v0.19 introduces a new interface anyway (App::Link), now would be a good time to move datum objects from PartDesign namespace to Part namespace. Few FreeCAD users are using PartDesign::CoordinateSystems until now, so few would be affected, and they would "
easily" understand that some interfaces have changed with the major upgrade of v0.19. For backwards compatibility, when opening an old FreeCAD file (v<0.19), each time a PartDesign::Plane is encountered it is interpreted as Part::DatumPlane and saved as such the next time. Easy.
I know that that would break quite some stuff, but it's better now than for v0.20. As I said earlier, it's not an Assembly4 request because it works very well like that, it's more a long-term investment request, such that the FreeCAD data format can be defined for the very long term: if the FreeCAD data structure stabilises it is reasonable to aim for a stable 1.0 release. It will cause some short-term pain, but with a huge long-term gain.