Old Workflow refactoring

[jmaustpc]

ickby, To be honest I was a bit frustrated, angry and whatever with your first post in the thread.


I apologize if I was a bit harsh, I did not intend to frustrate anyone. But I must also note that the whole new PartDesign idea exist for years, people have on and off worked on it for years, expecting to just step in and change fundamental things without any discussion is prone to lead to strong reactions. But let us keep this aside and try to come to a good technical solution.

Just a comment for perspective....as ickby said, this work flow was designed/intended years and years ago, the so called "current system" was always pretty much just a temporary "half job" ....this only seems like (and is) an issue because it has been so long since this work was started and has not made it to master. To give you some idea, we were talking about pushing this to master "sometime soon" something like 4 years ago.

I have often wondered if we would be better to have a new file extension for Assembly/body FreeCAD files to make it really obvious that they are different (of course file version number within the xml file partly does this to but does not make it so obvious to the user). Something like MS did for different reasons with ".doc" and ".docx", obviously they did that because they moved to xml files, but you can see what I mean.

[Fat-Zer]

I apologize if I was a bit harsh, I did not intend to frustrate anyone.

Nevermind... IMO I'm just an easy-to-frustrate person

(But I suppose the Yes/No must be interchanged on the "Does document have Bodies" field?)

Sure, or the condition may slightly change... like "There are any partdesigns outside of a body."

Yes, but in python you can always do anything crazy. Python is expert mode, so this is ok. Accidently of course is not ok and must be considered a bug.

IMHO at least whatever silly line would be written in python shouldn't result in a crash...

About expert/migration mode we can have a discussion, as long as there is a barrier for the normal user to get into this mode.

I suppose a preferences entry would be enough... Or at most an entry in the property editor.

a suggestion: make this partdesign a whole new workbench. New set of objects, new types. Rename old PartDesign to LegacyPartDesign, hide it by default, and let it support the old workflow, the way it is. Introduce tools to transfer designs to new structure (it can even be done by people, with Python, and after the merge). Then, some time later, kill the old workbench.

Personally, I don't really like the idea, but it doesn't sounds as absolutely not acceptable for me... Also I'm afraid it can bring merging of the branch far enough...

the so called "current system" was always pretty much just a temporary "half job"

There is nothing more persistent than temporary...

I have often wondered if we would be better to have a new file extension for Assembly/body FreeCAD files to make it really obvious that they are different (of course file version number within the xml file partly does this to but does not make it so obvious to the user).

I don't really see any sane reasons to migrate: We are not changing any file formats, we don't changing the hole system, just one essential parts... To migrate just to forbid to open old files in newer version of a program just sounds a bit silly for me...

[added]
DeepSOIC, what branch can be considered as current now?

[triplus]

To have PartDesign WB and PartDesign Legacy WB available at the same time? Huh.

How about "PartDesign WB NEW" and "Part WB NEW"? Therefore when user enters PartDesign it is confronted with the new behaviour but in Part WB basically current workflow would still be possible and old .fcstd files would therefore normally open and work there. Some tools from current PartDesign WB would therefore need to be moved in Part WB NEXT. Basically what i am proposing is to merge current PartDesign WB + current Part WB and label it Part WB.

That would remove the:

• Confusion of having 2 PartDesign WB.
• Old files and workflow would still be possible.
• Migration efforts could therefore be abandoned.
• Other workbenches not yet adopted to current PartDesign workflow might still work the same.
• Over time things could slowly adopt towards new PartDesign WB and new PartDesign WB could adopt some changes if it makes sense to change them.
• All new PartDesign WB introduced in master faster.

[ickby]

Hello guys,

I think I finished my work on PartDesign with the added corssreference code and unlimited sketcher links by deepSOIC. Even if not 100% perfect and for sure not bug free I think the workflow is done. The rest can be fine tunded in master. So two large things are still open:

1. Part Workbench adoptions
2. Migration.

As you started the old-workflow compatibility I propose to follow Fat-Zer's scheme he has given as graph a few slides earlier. I suppose we can all live with this sheme and it seems to be the fastest way to a mergable code. So if oyu guys are still willing to work on this I propose the following actions:

Fat-Zer/DeepSoic: Finish the old workflow support and implement the Fat-Zer sheme for workflow switch between old/new
Ickby: port Part Workbench

Would this be ok? Up to now I also worked on the not-rebased branch. I think using the rebased one is a good idea, we should just decide if we work on the same branch synchronous or have two different branches we merge at the end. I would go for the latter, as I suspect that the work does not interfere very much. Whats your opinion?

[DeepSOIC]

I agree. Except that I am going to return to freecad coding when I have my splinetravel up and running (hope to get first results/dry runs today)

[DeepSOIC]

SplineTravel takes more time than expected (usual state of things ). And for about two weeks I will be away from coding. Sorry.

[Fat-Zer]

Hey, I've got a yet another bright idea...
What if we add a "support feature" property for body (a link to Part::Feature)?

This will get the same meaning as support feature for the first solid. I suppose it would be enough to allow to migrate nearly any old file without breaking it as well as it will remove the "partdesign is getting to be splitted from all other workbenches" issue (e.g. we will be able again to pad/pocket on an Arch wall as wall as on any solid)...

[ickby]

This sound like a very good idea! Here is how I understand it, please check if we are on the same line and correct me if I got it wrong:

1. New Part Design only works for bodies and it is not possible to add PartDesign features outside of a body
2. It is possible to use the Body as a feature itself, placed on any Part::Feature, like Arch::Walls or old PartDesign features with the new support property
3. Old PartDesign features are still editable
4. File migration would work via putting everything from a document in a App::Part and then just let the user continue the modeling via creating a new Body which uses the last old modeling step as support

I really like this, it is a elegant way to get the closed and clean PartDesign workflow without loosing the generality of the workbench!

[Fat-Zer]

1. New Part Design only works for bodies and it is not possible to add PartDesign features outside of a body

yes

2. It is possible to use the Body as a feature itself, placed on any Part::Feature, like Arch::Walls or old PartDesign features with the new support property

Not quite understood that, you want to derive the Body from PartDesign::Feature or Part::Feature? hmm... not sure, haven't yet thought about it, this is a bit more than I've thought about, but it will bring lots of additional possibilities... If it will work it will be even better... Although I see some problems over there...
I'm talking about just adding a first-solid-feature property to body which required to be Part::Feature without changing any class hierarchy. And setting the first solid's BaseObject property inside the Body's Model to it...

3. Old PartDesign features are still editable
4. File migration would work via putting everything from a document in a App::Part and then just let the user continue the modeling via creating a new Body which uses the last old modeling step as support

I'd rather follow the previous consent here: either to use old workflow or to migrate and put all PD features inside bodies... But I suppose now mostly any file will be possible to migrate without breaking anything... So even unconditional migration or to forbid to add features outside bodies would be an option for me...

[Fat-Zer]

2. It is possible to use the Body as a feature itself, placed on any Part::Feature, like Arch::Walls or old PartDesign features with the new support property

Not quite understood that, you want to derive the Body from PartDesign::Feature or Part::Feature? hmm... not sure, haven't yet thought about it, this is a bit more than I've thought about, but it will bring lots of additional possibilities... If it will work it will be even better... Although I see some problems over there...

Oh... Body actually is a Part::Feature... So I suppose that can be considered as "yes"... =))
But I'd rather double check that it has correctly overloaded all required feature methods...