Code review of merged Link3 branch

[adrianinsaval]

Interesting, how do you propose this variants should be saved? embedded in the assembly file? If you add further features to the original file, how will they be updated in the variants?

screenshot.png (32.76 KiB) Viewed 1014 times

Unrelated cuestion: how did you make the "Variables" object, it seems very handy

[Zolko]

There is a difference in paths behaviour between realthunder's former FreeCAD-asm3 branch and the current FreeCAD-0.19-pre developper version: -asm3 saves relative paths for linked files while -pre saves absolute paths.

I did the exact same thing in both:

• create 3 new documents
• save them as asm, part1, part2, in the same directory
• close them
• re-open them
• create a link (not Assembly4 link, a pure App::Link) in asm
• assign the linked part as part1
• create a link in asm
• assign the linked part as part2
• save

then when I rename the directory, -asm3 finds the links again while 0.19-pre looses them. In the assembly's .fcstd file, the difference is clear:

-asm3:

Code: Select all

<Property name="LinkedObject" type="App::PropertyXLink" status="256">
<XLink file="part1.FCStd" stamp="2019-10-28T07:10:15Z" name="Part"/>
</Property>

-pre:

Code: Select all

<Property name="LinkedObject" type="App::PropertyXLink" status="256">
<XLink file="/home/hubertz/Documents/3Dcad/FreeCAD/Data/Test_v0.19/part1.FCStd" stamp="2019-10-28T07:19:20Z" name="Part" sub=""/>
</Property>

?

realthunder, did you modify the paths behaviour between -asm3 and 0.19-pre ? I think that the -asm3 behaviour was better, unless there is a way to specify absolute/relative paths manually.

[Zolko]

Interesting, how do you propose this variants should be saved? embedded in the assembly file?

well, first I think that these are still App::Link objects, so no, not in the assembly. What should be stored in the assembly is the base file and the variables that shall be modified to produce — on the fly, in RAM, not on disk — the variant. The point is also that this should be forward compatible, meaning that files produced today shall be usable in 10 years. But in 10 years people are going to come with new ideas. While it would be quite easy to come up with a solution for today, this would not scale well.

The minimum would be to store in the assembly:

• the base file : Path
• a boolean that it's a variant of that base file : isVariant
• the variant type (because I'm sure other people will have other use-cases in mind) : VariantType
• the variables that shall be changed and their values : a list

And then, according to the variant type, take evasive action. So for each App::Link, there should be 1 additional boolean property isVariant if "false" then it's a normal App::Link:

Code: Select all

<Object name="Part_1" Extensions="True">
  <Properties Count="18" TransientCount="0">
    ...
    <Property name="LinkedObject" type="App::PropertyXLink" status="256">
      <XLink file="part1.FCStd" stamp="2019-10-28T07:10:15Z" name="Part"/>
    </Property>
    <Property name="isVariant" type="App::PropertyBool" status="256">
      <Bool value="false"/>
    </Property>
    ...
  </Properties>
</Object>

If you add further features to the original file, how will they be updated in the variants?

To be clear, the primary use-case would be for families of parts, to be used as library, therefore the occurrence of the base part changing should be rare. When that happens, a command "Reload Variant" is needed, that re-fetches the base part from disk, and re-applies the variants changes to it. Thus, if additional functions have been added, they will be included also.

Unrelated cuestion: how did you make the "Variables" object, it seems very handy

They're FeaturePython objects. They're the poor man's spreadsheet. In a new document, try:

Code: Select all

App.ActiveDocument.addObject('App::Part','Model')
vars = App.ActiveDocument.getObject('Model').newObject( 'App::FeaturePython', 'Variables' )
vars.addProperty( 'App::PropertyBool', 'Variant', 'Variables' )
vars.Variant = True
vars.addProperty( 'App::PropertyFloat', 'Length', 'Variables' )
vars.Length = 10
vars.addProperty( 'App::PropertyEnumeration', 'Size', 'Variables' )
vars.Size = ['M2', 'M2.5', 'M3', 'M4', 'M5', 'M6']
vars.addProperty( 'App::PropertyString', 'Comment', 'Variables' )
vars.Comment = 'This is a comment'

[triplus]

@Zolko

This macro sounds similar ("Part Family"):

https://forum.freecadweb.org/viewtopic.php?f=22&t=18437
https://www.freecadweb.org/wiki/Macro_Alias_Manager

But i guess you would like to involve App::Link? Therefore i guess for App::Link being able to represent the same linked feature (shape) more times, each time the linked feature having a different property (like length) set? If each App::Link feature would need an underlying copy of the shape, then i don't see much benefit, compared to i guess using the approach 'Part Family' macro uses. If App::Link could work in a way, to build a representation, without needing an underlying copy after. Then i guess that might be worth exploring in the future.

P.S. Anyway, one practical/theoretical question, now that more than one developer has an in-depth understanding of the App::Link. Should App::Link and App::Part be merged in the future, or not?

[vocx]

...
... Should App::Link and App::Part be merged in the future, or not?

No, of course not. App::Part is a "group", App::Link just creates a link or reference to another object.

However, I think realthunder also created a "LinkGroup". This LinkGroup is basically a replacement for App::Part. So, I think he does in fact intend to merge the functionality of LinkGroup into App::Part.

[realthunder]

P.S. Anyway, one practical/theoretical question, now that more than one developer has an in-depth understanding of the App::Link. Should App::Link and App::Part be merged in the future, or not?

The merge is more or less done in my branch here, by merging some App::LinkGroup features into App::Part, so we'll be seeing App::Part more in the future.

[triplus]

And is App::LinkGroup more or less Assembly oriented, or it affects PartDesign (and other aspects of FreeCAD) too?

[realthunder]

And is App::LinkGroup more or less Assembly oriented, or it affects PartDesign (and other aspects of FreeCAD) too?

LinkGroup offers a coordinate system without any side effect. So when you add a sketch with external geometry, those referenced objects won't be added as a side effect. This may be good or bad depending on the use case. App::Part can achieve similar effect by adding Link. So my plan is to bring App::Part up front for the end user. And leave LinkGroup at the background for power user/developers. PartDesign body remains the same.

[triplus]

Would any of this work.

• Add PartDesign Body to App::LinkGroup.
• Add a combination of PartDesign CoordinateSystem and Part Cylinder to App::LinkGroup.

P.S. Additional question, do PoM and App::LinkGroup share any common goals?

[Zolko]

This macro sounds similar ("Part Family"):

https://forum.freecadweb.org/viewtopic.php?f=22&t=18437
https://www.freecadweb.org/wiki/Macro_Alias_Manager

are these families pre-built ? What I would like is to create a "Part" — rather: to link a Part — that is created on-the-fly, and whose variables can be modified even after creation.

But i guess you would like to involve App::Link? Therefore i guess for App::Link being able to represent the same linked feature (shape) more times, each time the linked feature having a different property (like length) set? If each App::Link feature would need an underlying copy of the shape, then i don't see much benefit, compared to i guess using the approach 'Part Family' macro uses.

Yes, if a new Variant is created, then it cannot share its geometry with the original, so yes, there needs to be some kind of copy. The difference is that the Variant would only be created in RAM, not on disk. Another difference is that you could create Variants of assemblies, where only the assembly would be duplicated, not the parts, and then in the variant assembly the same parts would be positioned differently, no shape would be copied.

And the point is: App::Link can already do exactly that, except that it cannot be saved to disk.

And I'm not the only one asking for this feature:

My intention was to use FreeCAD to draw one parametric chipboard cabinet, and import it several times but with different dimensions.
...
I need to somehow, unlink parts after import so I can change dimensions. I don't care if that would be simple copying, and I don't care about file sizes. I just need to avoid to draw cabinets all over again for every single cabinets case I need to build.