SheetMetal WB migration to 0.17

[yorik]

Basically we don't really integrate any new workbench into the freecad core code anymore because things have changed a lot, and it is not so interesting anymore... Python workbenches don't need to be integrated, they can be installed by the user, and we now have a nice addons manager that turns that very easy, and also the list of useful workbenches is growing very fast, so it would soon become impossible to merge them all, and there is the hassle of having to do pull requests, more work for everyone, while now every workbench author can work freely as he wants, etc.

In the past, including workbenches into the freecad code was th only way to have them delivered to the user.

A couple of things I'd like to improve, are 1) give better credit to the workbench authors, they are freecad developers too, they deserve to appear somewhere 2) make these workbenches more discoverable by the user (the start page maybe?) and 3) make their documentation more easily accessible

[kkremitzki]

A couple of things I'd like to improve, are 1) give better credit to the workbench authors, they are freecad developers too, they deserve to appear somewhere 2) make these workbenches more discoverable by the user (the start page maybe?) and 3) make their documentation more easily accessible

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? Example:

Code: Select all

---
fc-addon:
  - author: John Smith
  - shortname: My FreeCAD Addon
  - preview: std_imgXbyYpixels.png
  - description: >
    My multiline
    description string
    goes here.
...

That way, the addon manager can look for that file and parse it to get "nice" data about the addon, maintained by the addon developer, falling back to what we do now if the file isn't there. Additionally, I could add some sort of "featured addon" pane in the Start WB, which randomly picks from the set of FC addons which have a well-formed FCAddon.yml file, including the proper-sized picture to fit into the Start WB pane.

[shaise]

I definitely agree with Yorik, all extra workbenches should be as add-ons and not integrated. The built in add-on manager definitely makes it easier to use.
A nice upgrade to the add-on manager will be an extra description for add-on, even as simple as showing the README, as sometime it isn't that obvious from its name.

shai

[DeepSOIC]

I really want it to integrate seamlessly with the new part design workflow. However I'm a bit at a loss how to make that using pure python. I was looking for a simple python example to use it as a reference, but didn't found one yet.

I'm afraid this is impossible as of now. The main brick appears to be missing: PartDesign::FeaturePython.

I suddenly had a stupid idea. We can create an add-on workbench "PartDesign Legacy", that will simply replace the commands so that they don't require a body. This will work with actual PartDesign features, because they still support recomputing in the legacy workflow. OK, that is probably a really bad idea, asking for trouble... it's a bit easier to introduce PartDesign::FeaturePython. This should open the gate into the walled garden.

You can try to bodge your sheet-metal features into Bodies by directly overwriting "Group" property of body, instead of using addObject(). I think it bypasses the rules programmed into body to not accept anything non-partdesign. At least, I've successfully done so in pre-extension era, in part-o-magic, as a mock-up of Module container. But again, this is asking for trouble.

[shaise]

I'm afraid this is impossible as of now. The main brick appears to be missing: PartDesign::FeaturePython.

WOW! frightening telepathy!
I was just about to post a question about it...
I was poking around with the code trying to understand what to do and I stumbled into that: no PartDesign::FeaturePython so no option to dynamically add properties.
Any chance for that to happen? An option to extend part design will be really helpful not only to me.

shai

[DeepSOIC]

Any chance for that to happen? An option to extend part design will be really helpful not only to me.

I am giving it a try right now.

[DeepSOIC]

https://github.com/DeepSOIC/FreeCAD-ell ... rtDesignPy

@shaise: would you be so kind to give it a quick try? I haven't got time today to write a test python partdesign feature...

[ickby]

Hllo,
there should definitely be a PartDesign::FeaturePython. Making part design extensible from python is important.

Deepsoic's branch looks good. Shaise, I think your endeavour to port sheet metal to part design is a nice test bed. Please report any problems you encounter so that we can tackle them.

[shaise]

@shaise: would you be so kind to give it a quick try? I haven't got time today to write a test python partdesign feature...

Wow this was fast....
Its been several years since I last compiled freecad from source, (I mostly worked with python) but I will definitely give it a shot now...
shai

[shaise]

Deepsoic's branch looks good. Shaise, I think your endeavour to port sheet metal to part design is a nice test bed.

It took me some time to make the compilation work (does the CMAKE/compiler should have brought the extra libs needed in bin directory? cause I had to manually copy it from a release version)
Anyway indeed Deepsoic's branch seems to work. In fact, I'm amazed it works with such a small code change.
I've been able to bring a SeetMetal object into a PartDesign Body. I now need to work on the view provider, hopefully no missing python functionality there.
Also, I plan to make the module bi-functional: if you work on a part design part, it will follow the part design workflow. If you work on another part (say start with 'Part' workbench) it will work as legacy sheetmetal.

Thanks DeepSOIC !!

shai