SheetMetal WB migration to 0.17
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SheetMetal WB migration to 0.17
Great! Pull-request time, then...
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SheetMetal WB migration to 0.17
So that's just an initial window.
Also, we need to create python versions for PartDesign::FeatureAddSub (using this is required to make pattern features work with the custom PD feature), Part::Datum (to make something analogous to Datum Plane), and PartDesign::Transformed for custom pattern features.
Also, we need to create python versions for PartDesign::FeatureAddSub (using this is required to make pattern features work with the custom PD feature), Part::Datum (to make something analogous to Datum Plane), and PartDesign::Transformed for custom pattern features.
Re: SheetMetal WB migration to 0.17
Hi
Basic V0.17 implementation of SheetMetal is available at Branch V.017:
https://github.com/shaise/FreeCAD_SheetMetal/tree/V0.17
If you work within a selected PartDesign Body, it will continue the PartDesign scheme. On all other parts it will work as before.
Need to work on small details now.
Can anyone help with the following:
For a part design object, Is there any way to query the parent Body? Cant seem to find how to.
shai
Basic V0.17 implementation of SheetMetal is available at Branch V.017:
https://github.com/shaise/FreeCAD_SheetMetal/tree/V0.17
If you work within a selected PartDesign Body, it will continue the PartDesign scheme. On all other parts it will work as before.
Need to work on small details now.
Can anyone help with the following:
For a part design object, Is there any way to query the parent Body? Cant seem to find how to.
shai
Re: SheetMetal WB migration to 0.17
+1 to this idea. The addons are already high quality, most have their own issue tracker and wiki. This would also be a good landing spot for dependencies above standard FreeCAD dependencies. If the addons installer could gracefully degrade if the info was not available.kkremitzki wrote: I've considered something like this while looking at a preview pane for the addon manager. Part of the issue is that there isn't a standard way of getting info about the package besides (a) the addon manager keeping that info or (b) hoping that info is available in some sort of README.
Perhaps we could use some sort of simple, standardized metadata file? like a FCAddon.yml file?
@shaise, sorry for the thread hijack, we should move future discussions.
"fight the good fight"
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SheetMetal WB migration to 0.17
Not yet. Ickby is busy with extending container api, see https://forum.freecadweb.org/viewtopic.php?f=10&t=20749 . I think he exposed a method to get a container of a feature. But it isn't in master, and he plans a rework (maybe it's already in progress, I don't know).shaise wrote:For a part design object, Is there any way to query the parent Body? Cant seem to find how to.
As of right now, I think you have to roll your own routine for finding a body.
Re: SheetMetal WB migration to 0.17
Ok. Did it by iteration on the Body's Group.DeepSOIC wrote:As of right now, I think you have to roll your own routine for finding a body.
I have added now some restrictions with warning messages to prevent cross coordinate links. Now sheet metal manipulation is restricted inside a Body.
Can anyone tell me if there are any special methods in view provider that must be implemented for PartDesign features? I use pretty standard one just not claiming children to prevent nesting. All commited to branch V0.17.
@DeepSOIC, thanks again for the PartDesign::FeaturePython fix, I'm pretty amazed how fast you pulled this up.
shai
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SheetMetal WB migration to 0.17
I don't quite know, and it caused a bit of confusion when making the FeaturePython. PartDesign::Feature does not override Part::Feature's viewprovider, so it is the viewprovider it gets by default. I made it the same for FeaturePython. However, there is a ViewProvider.h/ViewProvider.cpp in PartDesign, which looks like should have been bound to PartDesign::Feature, but apparently isn't. It might be just a small overlooked issue, because PartDesign::Feature isn't used by partdesign in its pure form, it is only a base for making derivatives from.shaise wrote:Can anyone tell me if there are any special methods in view provider that must be implemented for PartDesign features?
This might in theory cause some unexpected crashes or otherwise faulty behavior when other PartDesign things hook onto python features. We'll see...
EDIT: this post I hard to understand I'll try to rewrite it.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SheetMetal WB migration to 0.17
OK, rewriting...
There is PartDesign::Feature, and PartDesign::ViewProvider. However, PartDesign::Feature doesn't use PartDesign::Viewprovider. This is strange...
I followed this when creating a python variant:
This might cause trouble, because PartDesign's gui code might expect that a viewprovider of a PartDesign::Feature-derived object is derived from PartDesign::ViewProvider. This expectation is likely true for all PartDesign objects, because PartDesign::Feature is never used in its bare form.
There is PartDesign::Feature, and PartDesign::ViewProvider. However, PartDesign::Feature doesn't use PartDesign::Viewprovider. This is strange...
Code: Select all
>>> App.ActiveDocument.addObject("PartDesign::Feature")
<PartDesign::Feature>
>>> App.ActiveDocument.ActiveObject.ViewObject.TypeId
'PartGui::ViewProviderPart' #not PartDesign??
Code: Select all
App.ActiveDocument.addObject("PartDesign::FeaturePython")
<PartDesign::Feature>
>>> App.ActiveDocument.ActiveObject.ViewObject.TypeId
'PartGui::ViewProviderPython' #not PartDesign!
Re: SheetMetal WB migration to 0.17
Well, this might explain why sheetmetal works good with the standard view providerDeepSOIC wrote:However, PartDesign::Feature doesn't use PartDesign::Viewprovider. This is strange...
Anyways, I found lots of other issues with SheetMetal, Probably because of change of OCC, so I'm fixing it now. Hopefully till your (@DeepSOIC) changes will be merged, I will have a working version which is backward compatible with V0.16
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SheetMetal WB migration to 0.17
I have updated the branch to use PartDesign's viewprovider. (Warning: forced update!)
Now I can answer your question better:
* call ViewObject.setBodyMode(True) if you add the new feature to a body. This will hide most view properties (e.g., Color), and make them controlled by Body. no you don't!, happens by itself!
Omitting the call shouldn't be a big deal...
I exposed another handy method, makeTemporaryVisible(). Use it if needed.
You don't need to implement any extra methods in your python proxy object, as of now (and neither does the viewprovider offer any extra overrides). Maybe in the future, when stuff like AddSub is exposed.
Would you be so kind to test it again?
BLUE = edits
Now I can answer your question better:
You should:shaise wrote:Can anyone tell me if there are any special methods in view provider that must be implemented for PartDesign features?
* call ViewObject.setBodyMode(True) if you add the new feature to a body. This will hide most view properties (e.g., Color), and make them controlled by Body. no you don't!, happens by itself!
Omitting the call shouldn't be a big deal...
I exposed another handy method, makeTemporaryVisible(). Use it if needed.
You don't need to implement any extra methods in your python proxy object, as of now (and neither does the viewprovider offer any extra overrides). Maybe in the future, when stuff like AddSub is exposed.
Would you be so kind to test it again?
BLUE = edits