What is the best path into V1.0

[cchurms]

Good morning coders:

I am working with a few guys on a workbench, which is still in its early stages. The workbench gets around the toponaming issue by using assembler to put bodies together.

With the advent of 0.20 (great work guys!!!) the workbench is somewhat broken, and I am about to work on the bugs. However, I would like to code so as to follow the best path into 1.0, as there is bound to be code in "our" workbench, which must be adapted once 1.0 arrives. (2023 ?)

As is well-known (by members of this group), assembler2, assembler3 and assembler4 use relatively widely disparate approaches. My question is:

Which assembler approach is 1.0 most likely to resemble? i.e. I gather that 1 .0 will have some code and strategies which will be migrated from the assembler "family". After all, the assembler workbenches are each, in their own way, striving towards both assembly capability, and the end of toponaming issues. I believe that 1.0 will have addressed both. Which of assembler, assembler2, assembler3 and assembler4 will have the largest influence on how 1.0 will approach matters?

I am aware that the most likely and logical answer should be "Wait for 1.0 to come out, and you will see." However, I am sure you guys who are already working on 1.0 will have an infinitely better idea of what is in the pipeline, than I do.

All I ask for is some guidance, and not necessarily final commitment. Even if your guidance turns out not to be the way things go in the end, any guidance now, is worth much more than my ignorance.

Thanks
Cecil (cchurms)

[NewJoker]

The goal for 1.0 is to eliminate the topological naming issue with the help of Realthunder's fixes that are going to be merged into the master so that no workarounds are needed for TNP anymore. However, there's no official decision yet on which assembly module will be implemented in FreeCAD. Unfortunately, it may also happen that there will be no single assembly module built into FreeCAD and the users will still have to choose from multiple add-on assembly modules.

[Kunda1]

Clarification: assembly not assembler

Relevant links on 'toponaming'

• https://github.com/realthunder/FreeCAD#readme <--realthunder's branch in which his fix is implemented
• https://github.com/realthunder/FreeCAD_ ... cal-Naming <-- write-up on the toponaming fix
• https://github.com/FreeCAD/FreeCAD/tree ... toponaming <-- The FreeCAD branch where toponaming fix will be implemented
• https://forum.freecadweb.org/viewtopic.php?f=10&t=68032 <-- Announcement by the devs regarding the toponaming fix and timeline

Edit: you could consider teaming up with Zolko (the Assembly4 dev) and Realthunder (Assembly3 dev) to help work on unifying said workbenches in to one assembly workbench?

Edit2: Hey @Zolko where is the thread on unifying the Assembly workbenches ?

[chrisb]

where is the thread on unifying the Assembly workbenches ?

Here is one of these https://forum.freecadweb.org/viewtopic.php?f=20&t=40058.

[adrianinsaval]

Unfortunately it doesn't look like anyone else (doing development of those wb) besides zolko is onboard for convergence.

[Kunda1]

We should check in on the A2plus dev and see how he's doing (after that freak flooding that hit his town).

[cchurms]

Thanks Gents

Thanks for the insightful comments and pointers. They are just what I was looking for.

[ Yes, Assembly. I am so used to coding in assembler, ever since the 6800 and 6502 days, that I neglected to differentiate between assembling parts together, and assembling CPU instructions together. ]

Regards
Cecil

[Zolko]

The goal for 1.0 is to ...

I don't think that this is the good approach. v1.0 is not a decision, but an observation : "yes, the software is stable, we can call it v1.0". Deciding, in advance, that the next release is going to be v1.0, and then see that "oops, we didn't think of this" will very much hurt the acceptance of the larger public. If anything, it should be called v0.99, showing that the purpose is v1.0 in the medium-term

The goal for v1.0 should be data stability, meaning that any data produced today will still be usable in 10-20 years: like HTTP, PDF, e-mail, SMS, STEP, STL ... And that includes assembly files. So it's not so much the assembly workbench that should be decided upon, but the data format.

From what I've understood, it had been decided long ago that Std_Part shall be the assembly container, and with realthunders App::Link, this is a very nice, stable and powerful combination. Unfortunately, realthunder decided to use another data format for Asm3 containers. I don't know how difficult it would be to change Asm3 to use Std_Part as its assembly container.

[obelisk79]

From what I've understood, it had been decided long ago that Std_Part shall be the assembly container, and with realthunders App::Link, this is a very nice, stable and powerful combination. Unfortunately, realthunder decided to use another data format for Asm3 containers. I don't know how difficult it would be to change Asm3 to use Std_Part as its assembly container.

Perhaps @realthunder can chime in?

[realthunder]

Yes, the unification of assembly container has to be done eventually, but it's not the first priority of the next release. I'm not sure there will be time for it. I do hope though.