Code review of merged Link3 branch

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Code review of merged Link3 branch

Post by adrianinsaval »

Zolko wrote: Fri Oct 25, 2019 1:06 pm
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
screenshot.png (32.76 KiB) Viewed 1866 times
Unrelated cuestion: how did you make the "Variables" object, it seems very handy
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Code review of merged Link3 branch

Post by 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 wrote: Thu Oct 24, 2019 12:36 am ?
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.
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Code review of merged Link3 branch

Post by Zolko »

adrianinsaval wrote: Mon Oct 28, 2019 3:58 am 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>
adrianinsaval wrote: Mon Oct 28, 2019 3:58 am 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.

adrianinsaval wrote: Mon Oct 28, 2019 3:58 am 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'
try the Assembly4 workbench for FreCAD — tutorials here and here
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Code review of merged Link3 branch

Post by 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
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: Code review of merged Link3 branch

Post by vocx »

triplus wrote: Wed Nov 13, 2019 10:42 pm ...
... 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.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Code review of merged Link3 branch

Post by realthunder »

triplus wrote: Wed Nov 13, 2019 10:42 pm 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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Code review of merged Link3 branch

Post by triplus »

And is App::LinkGroup more or less Assembly oriented, or it affects PartDesign (and other aspects of FreeCAD) too?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Code review of merged Link3 branch

Post by realthunder »

triplus wrote: Fri Nov 15, 2019 6:29 pm 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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Code review of merged Link3 branch

Post by triplus »

Would any of this work.
P.S. Additional question, do PoM and App::LinkGroup share any common goals?
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Code review of merged Link3 branch

Post by Zolko »

triplus wrote: Wed Nov 13, 2019 10:42 pm 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.

triplus wrote: Wed Nov 13, 2019 10:42 pm 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:

joe.belladonna wrote: Sun Nov 17, 2019 3:34 pm 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.

try the Assembly4 workbench for FreCAD — tutorials here and here
Post Reply