PD NEXT Roadmap towards 0.17 release
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: PD NEXT Roadmap towards 0.17 release
Good to see you are eager to work on PartDesign NEXT Abdullah. Be patient would be my suggestion.
I remember when i provided some early feedback and how it after took a year or two for different developer to diagnose the same thing and implement it. In that time between i realized way more users need to start testing and providing feedback. As PartDesign NEXT was basically envisioned by a handful of developers and i do imagine was used by a handful of users. And it is just counter productive to give much feedback in this stage. FreeCAD 0.17 will get released and after user feedback will come. That was my conclusion.
Therefore get familiar yourself with PartDesign NEXT as much as you can and try to listen to user feedback in FreeCAD 0.18 development cycle. For FreeCAD 0.17 development cycle i guess your best bet is to involve yourself in GSoC project as much as you can. Like as you where a mentor/student participating in it. As there is likely where the PartDesign NEXT momentum will be.
I remember when i provided some early feedback and how it after took a year or two for different developer to diagnose the same thing and implement it. In that time between i realized way more users need to start testing and providing feedback. As PartDesign NEXT was basically envisioned by a handful of developers and i do imagine was used by a handful of users. And it is just counter productive to give much feedback in this stage. FreeCAD 0.17 will get released and after user feedback will come. That was my conclusion.
Therefore get familiar yourself with PartDesign NEXT as much as you can and try to listen to user feedback in FreeCAD 0.18 development cycle. For FreeCAD 0.17 development cycle i guess your best bet is to involve yourself in GSoC project as much as you can. Like as you where a mentor/student participating in it. As there is likely where the PartDesign NEXT momentum will be.
Re: PD NEXT Roadmap towards 0.17 release
I am looking at it now. I did not manage to find an associated bug report. Is there none?NormandC wrote:That's great news.
Now it would be great to see the annoying "Can't find Origin for Body/Part" error in report view when opening an existing file eradicated from existence.
Re: PD NEXT Roadmap towards 0.17 release
issue #2665abdullah wrote:I am looking at it now. I did not manage to find an associated bug report. Is there none?NormandC wrote:That's great news.
Now it would be great to see the annoying "Can't find Origin for Body/Part" error in report view when opening an existing file eradicated from existence.
issue #2642
issue #2530
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: PD NEXT Roadmap towards 0.17 release
This one is the good one:Kunda1 wrote: abdullah wrote:
NormandC wrote:
That's great news.
Now it would be great to see the annoying "Can't find Origin for Body/Part" error in report view when opening an existing file eradicated from existence.
I am looking at it now. I did not manage to find an associated bug report. Is there none?
issue #2665
issue #2642
issue #2530
https://freecadweb.org/tracker/view.php?id=2530
In the others, this error appears just because it always appears, but they are not related at all (the bug is not in this code).
I know when it happens now. At loading of a file, in the updateData call, when the extensions are called, the updateData cannot determine the Origin on this execution (it returns null). Now I have to understand what is different in this execution and for that I have to better understand extensions...
Code: Select all
#0 App::OriginGroupExtension::getOrigin() at /home/abdullah/github/free-cad-code/src/App/OriginGroupExtension.cpp:51
#1 Gui::ViewProviderOriginGroupExtension::updateOriginSize() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderOriginGroupExtension.cpp:146
#2 Gui::ViewProviderOriginGroupExtension::extensionUpdateData() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderOriginGroupExtension.cpp:110
#3 Gui::ViewProvider::updateData() at /home/abdullah/github/free-cad-code/src/Gui/ViewProvider.cpp:642
#4 Gui::ViewProviderDocumentObject::updateData() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderDocumentObject.cpp:193
#5 Gui::ViewProviderGeometryObject::updateData() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderGeometryObject.cpp:190
#6 PartGui::ViewProviderPartExt::updateData() at /home/abdullah/github/free-cad-code/src/Mod/Part/Gui/ViewProviderExt.cpp:834
#7 PartDesignGui::ViewProviderBody::updateData() at /home/abdullah/github/free-cad-code/src/Mod/PartDesign/Gui/ViewProviderBody.cpp:302
#8 Gui::ViewProviderDocumentObject::updateView() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderDocumentObject.cpp:156
#9 Gui::Document::slotNewObject() at /home/abdullah/github/free-cad-code/src/Gui/Document.cpp:433
== BOOST signaling ==
#23 App::Document::addObject() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:2201
#24 App::Document::readObjects() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:1308
#25 App::Document::Restore() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:1214
#26 App::Document::restore() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:1578
#27 App::Application::openDocument() at /home/abdullah/github/free-cad-code/src/App/Application.cpp:503
#28 App::Application::sOpenDocument() at /home/abdullah/github/free-cad-code/src/App/ApplicationPy.cpp:196
Second pass success, so it may be that simply origin should not be read in the first pass when restoring...
Code: Select all
#0 App::OriginGroupExtension::getOrigin() at /home/abdullah/github/free-cad-code/src/App/OriginGroupExtension.cpp:51
#1 Gui::ViewProviderOriginGroupExtension::updateOriginSize() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderOriginGroupExtension.cpp:146
#2 Gui::ViewProviderOriginGroupExtension::slotChangedObjectGui() at /home/abdullah/github/free-cad-code/src/Gui/ViewProviderOriginGroupExtension.cpp:132
== BOOST ==
#16 Gui::Document::slotChangedObject() at /home/abdullah/github/free-cad-code/src/Gui/Document.cpp:522
== BOOST ==
#30 App::Document::onChangedProperty() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:954
#31 App::DocumentObject::onChanged() at /home/abdullah/github/free-cad-code/src/App/DocumentObject.cpp:420
#32 Part::Feature::onChanged() at /home/abdullah/github/free-cad-code/src/Mod/Part/App/PartFeature.cpp:143
#33 Part::BodyBase::onChanged() at /home/abdullah/github/free-cad-code/src/Mod/Part/App/BodyBase.cpp:99
#34 PartDesign::Body::onChanged() at /home/abdullah/github/free-cad-code/src/Mod/PartDesign/App/Body.cpp:449
#35 App::Property::hasSetValue() at /home/abdullah/github/free-cad-code/src/App/Property.cpp:125
#36 App::PropertyLink::setValue() at /home/abdullah/github/free-cad-code/src/App/PropertyLinks.cpp:84
#37 App::PropertyLink::Restore() at /home/abdullah/github/free-cad-code/src/App/PropertyLinks.cpp:154
#38 App::PropertyContainer::Restore() at /home/abdullah/github/free-cad-code/src/App/PropertyContainer.cpp:238
#39 App::ExtensionContainer::Restore() at /home/abdullah/github/free-cad-code/src/App/ExtensionContainer.cpp:301
#40 App::Document::readObjects() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:1333
#41 App::Document::Restore() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:1214
#42 App::Document::restore() at /home/abdullah/github/free-cad-code/src/App/Document.cpp:1578
#43 App::Application::openDocument() at /home/abdullah/github/free-cad-code/src/App/Application.cpp:503
#44 App::Application::sOpenDocument() at /home/abdullah/github/free-cad-code/src/App/ApplicationPy.cpp:196
Re: PD NEXT Roadmap towards 0.17 release
I will call it a day.
The problem originates in that:
initializes the Origin property to null.
Then as shown in the previous post, during Document::Restore => readObjects => addObject => slotNewObject => ViewProviderDocumentObject::updateView => ViewProviderBody::updateData => ViewProviderGeometryObject::updateData => ViewProviderDocumentObject::updateData => ViewProvider::updateData => ViewProviderOriginGroupExtension::extensionUpdateData => updateOriginSize() => OriginGroupExtension::getOrigin, the latter throws an exception because the origin property is null.
Afterwards, the origin property is initialized during Document::Restore => readObjects => ExtensionContainer::Restore() => PropertyContainer::Restore() => App::PropertyLink::Restore() => App::PropertyLink::setValue() => Property::hasSetValue, which triggers an onChange: Body::onChanged => BodyBase::onChanged => Feature::onChanged => DocumentObject::onChanged => Document::onChangedProperty => Document::slotChangedObject => ViewProviderOriginGroupExtension::slotChangedObjectGui => ViewProviderOriginGroupExtension::updateOriginSize => OriginGroupExtension::getOrigin, now, the latter that is the same that was throwing the exception and generating the error message above, does not throw anymore because Origin has been initialized.
As for providing a solution, I think somebody "from above" should take a look as I do not know which was the criteria when creating extensions and thus the intended behaviour. Some idea may be to modify extensions to provide a mechanism to mark whether there is an ongoing process of restoring and simply do not "updateOriginSize" if there is such a restoring ongoing.
The problem originates in that:
Code: Select all
OriginGroupExtension::OriginGroupExtension () {
initExtensionType(OriginGroupExtension::getExtensionClassTypeId());
EXTENSION_ADD_PROPERTY_TYPE ( Origin, (0), 0, App::Prop_Hidden, "Origin linked to the group" );
}
Then as shown in the previous post, during Document::Restore => readObjects => addObject => slotNewObject => ViewProviderDocumentObject::updateView => ViewProviderBody::updateData => ViewProviderGeometryObject::updateData => ViewProviderDocumentObject::updateData => ViewProvider::updateData => ViewProviderOriginGroupExtension::extensionUpdateData => updateOriginSize() => OriginGroupExtension::getOrigin, the latter throws an exception because the origin property is null.
Afterwards, the origin property is initialized during Document::Restore => readObjects => ExtensionContainer::Restore() => PropertyContainer::Restore() => App::PropertyLink::Restore() => App::PropertyLink::setValue() => Property::hasSetValue, which triggers an onChange: Body::onChanged => BodyBase::onChanged => Feature::onChanged => DocumentObject::onChanged => Document::onChangedProperty => Document::slotChangedObject => ViewProviderOriginGroupExtension::slotChangedObjectGui => ViewProviderOriginGroupExtension::updateOriginSize => OriginGroupExtension::getOrigin, now, the latter that is the same that was throwing the exception and generating the error message above, does not throw anymore because Origin has been initialized.
As for providing a solution, I think somebody "from above" should take a look as I do not know which was the criteria when creating extensions and thus the intended behaviour. Some idea may be to modify extensions to provide a mechanism to mark whether there is an ongoing process of restoring and simply do not "updateOriginSize" if there is such a restoring ongoing.
Re: PD NEXT Roadmap towards 0.17 release
I have kept investigating. I wondered why this error messages appeared when loading a file, but not when creating a body directly.
The reason is that in addObject, when creating a new object, isNew==true; whereas when loading a file, isNew==false. Therefore, when loading a file setupObject is not executed. SetupObject, effectively initializes the extension via: Body::setupObject => DocumentObject::setupObject => OriginGroupExtension::onExtendedSetupObject.
As DocumentObject code is generic for all objects (workbenches), by design it was chosen to initialize the object only if new. Therefore a object or an extension of a object being restored, between the addition (addObject) and the restoring of the properties, must by design expect it not to be initialized.
The reason is that in addObject, when creating a new object, isNew==true; whereas when loading a file, isNew==false. Therefore, when loading a file setupObject is not executed. SetupObject, effectively initializes the extension via: Body::setupObject => DocumentObject::setupObject => OriginGroupExtension::onExtendedSetupObject.
Code: Select all
DocumentObject * Document::addObject(const char* sType, const char* pObjectName, bool isNew)
{
[more code here]
// Call the object-specific initialization
if (!d->undoing && !d->rollback && isNew) {
pcObject->setupObject ();
}
[more code here]
Re: PD NEXT Roadmap towards 0.17 release
I have come with a solution. Still to be seen if it is deemed acceptable or not:
https://github.com/FreeCAD/FreeCAD/pull/785
Basically, following the conclusion that an extension has to accept that its properties may not be initilised between the object creation at the restore of the document and the restore of the properties of the extension itself, the solution comes from not reporting the exception when it was not really an exception, i.e. when a document is restoring.
While there is a mechanism for checking whether a Object is being restored there was none for a Document being restored. First commit provides this mechanism. Second commit makes use of it so that the annoying text in: #2530 is, and I quote:
https://github.com/FreeCAD/FreeCAD/pull/785
Basically, following the conclusion that an extension has to accept that its properties may not be initilised between the object creation at the restore of the document and the restore of the properties of the extension itself, the solution comes from not reporting the exception when it was not really an exception, i.e. when a document is restoring.
While there is a mechanism for checking whether a Object is being restored there was none for a Document being restored. First commit provides this mechanism. Second commit makes use of it so that the annoying text in: #2530 is, and I quote:
NormandC wrote: eradicated from existence.
Re: PD NEXT Roadmap towards 0.17 release
Any other PDN annoying bug?
Re: PD NEXT Roadmap towards 0.17 release
Have not used PDN in a while, but from the top of my head I can remember the the viewport is often moved or not automatically updated, so that you need to zom or pan to get back to the objects you are working on. One is sometimes also rotated to the backside of objects when executing commands, witch can have some nauseating and anti productive effects.
Sorry for the low quallity report
Sorry for the low quallity report
Need help? Feel free to ask, but please read the guidelines first
Re: PD NEXT Roadmap towards 0.17 release
Hello Abdullah,
if you feel adventurous for some backend work I can present you an issue worth working on It basically is about the handling of the new GeoFeatureGroup and how it interacts with the objects it holds. Th eproblems are:
- Howto ensure each object is only in a single Group and a single GeoFeatureGroup
- How to forbid links that reach out of the objects own GeoFeatureGroup (And introduce a new link type that allows such cross-GeoFeatureGroup links)
- Howto handle Drag'n'Drop or any other object moving between groups
I startet with this in the folowing branch:
https://github.com/ickby/FreeCAD_sf_mas ... PartDesign
The moving and drag'n'drop logic works already nicely, but has the problem that it gets into endless recursion when the document object graph is cyclic. I tried to ensure that directly within the links itself by forbidding non-DAG links as well as Cross-GeoFeatureGroup links, but this seems to be very wonky.
Maybe you can put in some clever ideas, as I'm not able to code much in th enext months.
Stefan
if you feel adventurous for some backend work I can present you an issue worth working on It basically is about the handling of the new GeoFeatureGroup and how it interacts with the objects it holds. Th eproblems are:
- Howto ensure each object is only in a single Group and a single GeoFeatureGroup
- How to forbid links that reach out of the objects own GeoFeatureGroup (And introduce a new link type that allows such cross-GeoFeatureGroup links)
- Howto handle Drag'n'Drop or any other object moving between groups
I startet with this in the folowing branch:
https://github.com/ickby/FreeCAD_sf_mas ... PartDesign
The moving and drag'n'drop logic works already nicely, but has the problem that it gets into endless recursion when the document object graph is cyclic. I tried to ensure that directly within the links itself by forbidding non-DAG links as well as Cross-GeoFeatureGroup links, but this seems to be very wonky.
Maybe you can put in some clever ideas, as I'm not able to code much in th enext months.
Stefan